I am working on DW with SSAS cube. While development, my Cube is hosted on SQL SERVer 2008R2 on a development Server (Windows Server 2003).
Now, post to development phase I need to host the cube on test Server which would be on a remote location to which I do not have the access.
What are the possible ways I can host it on the server keeping in mind that If needed I need to re-deploy on server from BIDS Studio (when some bug arises).
What credentials I'll be needing (Will it do If I have a SQL sys rights or a windows account in that domain is a must)?
Thanks in advance!!1
In theory you shouldn't worry about it, taking into consideration of course, you have someone with access to the destination server.
You should never use BIDS to deploy your cube, it cant deal with partitions or security for example. Every deployment would overwrites these management settings of the target server.
Instead, you should use the Deployment Wizard to create your script and the you would send it to the person responsible for the deployment.
If you need more info about the deployment wizar, check my answer on this post
Related
I've setup a Service Broker on one of databases to automatically pick up stored procedures in a specific schema (Build) and run them on a daily basis. So far everything has been running fine, however we've now got a need where we need to access a remote sql server which is running SQL Server 2017 and has the latest Machine Learning Service installed.
I've given the service account that runs the primary SQL Server (SQL 2016) access on the remote server, and ensured the Service Broker is executing under the service account, rather than the local SQL account (sa).
Whenever we try to access the remote server, we are getting the following error:
Linked servers cannot be used under impersonation without a mapping
for the impersonated login.
I've tried adding an EXECUTE AS to the process, however this doesn't seem to make a difference. I've also ensured it is running under the service account, and it is.
I can get it to work using a mapped login on the linked server, however this isn't ideal, as we don't want to run the sql server in mixed authentication as this has been determined as an IT risk.
I've run out of ideas or what I can do here, and can't find any other help pieces with this same problem. I did want to roll this process out to more of our warehouse builds, however this is a deal breaker at this stage.
help?
I am looking to create a database server that can be used to store data using a VB.net application. When I initially installed SQL Server 2005 Express edition, I believe I installed this using the LocalDB option.
As it stands my application is a simple tool which utilises the Process.Start command under certain situations, depending on user input, to launch Game Servers for use at a gaming LAN I assist in running.
I wish to progress the application by being able to update, delete and query a database created in SQL Server 2005 Express. I understand the use of connection strings etc, however I am wondering if the installation using LocalDB will mean that I cannot connect to the server to process the data I require.
Can I continue to use the LocalDB option and create a Database Server for specific use using my application or is a different installation option required?
Secondly, can someone point me in the right direction of how to create a new Server for this purpose? All of my searches so far have provided results for creating a database only, and not the server.
I have a couple questions about what you are trying to do.
First, why are you installing SQL Server 2005? It was released almost a decade ago.
I would go with 2012 express edition.
http://www.microsoft.com/en-us/download/details.aspx?id=29062
Second, install the management tools. SSMS is a nice GUI to do work in.
Third, If you are spinning up anything other than express, there are licensing costs which are quite high. 9K for standard and 25K for enterprise per socket or such.
Here are the versions and features list from microsoft.
http://technet.microsoft.com/en-us/library/ms144275.aspx
Last but not least, having the express edition on another computer is fine. However, you will have to use a network protocol such as TCP/IP instead of shared memory.
It will take longer to send Tabular Data Stream (TDS) to the other computer versus talking to memory on the same computer.
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/c4f06669-41fd-42e6-b4a9-564cf04ca9f7/how-to-choose-between-shared-memory-named-pipes-tcpip-via?forum=sqlgetstarted
Good luck with your project.
You can use a local instance of SQL Server just fine, if you want to set up a separate server for some reason then you'll need either a 2nd machine on which to install SQL Server, or to spin up a virtual machine. If running Windows 8 (and barring hardware limitations) you have Hyper-V at your fingertips.
This is not a complete answer for you but may give you some things to think about.
First you might want to think about your choice of database. If you don't have a compelling reason for using 2005 you will probably at least want to move to SQL Express 2008.
Second, to answer the part about creating a server... A server is something that serves data. In a general sense a computer configured to be contacted by external machines and respond with data is a server. A web server runs a program like IIS or Apache to respond with web pages. A database server contains a database and allows connections to that database. So as long as you install the database on a computer and configure it to allow external connections, you have your database server.
In MS SQL there are several things that need to be set up to allow a database to accept external connections. One is that the SQL Server Browser service will need to be active. Another is that the database itself will need to be configured to allow external connections (SQL Authentication type probably).
Hope this helps.
Addition:
SQL Remote Connection Configuration
Disclaimer, I don't have SQL Express 2005 installed but I think the settings are found in the same place in 2008. If the info here is not exact to SQL Express 2005, the general terminology used here should be enough to get you headed in the right direction to find the specifics.
While viewing the database in Server Management Studio or Enterprise Manager, right click the database server instance name (the root of the tree) and select properties. There should be a section title Connections and within this section there should be an option "Allow remote connections to this server". Make sure it is checked. The other setting you need in this properties menu is under the security area. There is a radio button for "Windows Authentication Mode" and "SQL Server and Windows Authentication Mode", you want the second that allows both.
The next step you have may be to create a new user, add a password, and connect the user to the database. That will give you the credentials you will use in your database connection string while programming. I usually add new users through the security section of the database then set the User Roles for each database that I need to connect to. It is good practice to limit the permissions to those needed by the application. Typically this is read and write, but sometimes you can get away with just read. The less the better.
I am a total newbie in SQL/SQL server stuff, and I am using SSRS to make a new reporting server/service and upload some .rdl files to it
I have a reporting server on a machine, which has a lot of reports and data sources uploaded to it's database.
I created a new reporting server with a fresh database on another machine, and what I want to do is to copy the old database content to the fresh one (the reports and the datasources..etc)
I have no copy of the individual reports to upload them to the new server using localhost/reports
is there's a fast solution to what i am having? please do it in detail because I never worked with SQL before.
Different ways to do this:
Report Server Databases
Use the detach/attach or backup/restore instructions here. Both of these methods require a backup of encryption keys on the existing instance, which are then restored to the new report server instance. Instructions on backup/restore of encryption keys here. Migrating the ReportServer and ReportServerTempdb databases is the easiest way to ensure all content is available on the new server.
Report Object Scripting
Reporting Services Scripter is an older (but still working with SSRS 2008R2, not sure about 2012) tool that can be used to transfer objects (folders, shared data sources, shared data sets, reports, etc) between report servers. Good choice if you want to pick and choose what is migrated.
If you are receiving an error regarding unsupported scale-out deployment, this means you are running Standard edition and need to remove the old report server entry from the database in the new location. It can be done using Reporting Services Configuration Manager, or by using rskeymgmt at command line.
Reporting Services Configuration Manager
Open Reporting Services Configuration Manager and connect to the new report server instance.
Click on Scale-out Deployment to view registered report servers.
Select the old report server instance and click the Remove Server button.
Command line and rskeymgmt
Browse to the Tools\Binn folder of your SQL Server client installation.
Run the following to list registered report servers
rskeymgmt -l -i
Using the installation ID (GUID) of the old report server, remove it
rskeymgmt -r -i
More info on scale-out deployments and rskeymgmt here.
To migrate Reporting Services, use migration manual from MSDN (https://msdn.microsoft.com/en-us/library/ms143724(v=sql.120).aspx). If you encounter "the feature: scale-out deployment is not supported in this edition of reporting services. (rsoperation notsupported)" error, go to ReportServer database and remove the old encryption key from table dbo.Keys.
I have a powercenter 9.1 installation on windows server 2008 R2.
The repository is on the same box, hosted on sql server 2012. I have configured a new user (with sql server authentication) and have the repo db owned by that user. (it has the owner role)
The core problem : I am not able to run a simple test workflow on this setup.
Here's what I have been trying
The windows firewall has been taken down now for about an hour or so.
The repository service and integration service are running in trace/debug mode respectively.
The integration service log complains that it cant find a certain session for a certain workflow in certain folder (with ids for all of them).
When I log into sql server mgmt console, and try to query the repository tables for those exact items (since i have the ids from logs), all the data is present...
I fail to understand what is that I am messing up...
Disclaimer - my knowledge of sql server is really low.. may be 1 or 2 on scale of 10, since I have been living on the other side of fence (with oracle) for all of my career...
Did you try keeping the sql server login/user name and the associated default schema name as same?
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone