A couple of days back we moved our SQL Server database from a Physical server to a VM based server.
There were some reports in the reporting database which we skipped.
Now we cannot start the sql server instance on the old physical server, as the host name now points to the new vm based server in the DNS.
Can I just copy the reporting server database data and log files from the old server and attach them in the new server ? Would it work ?
Any help would be appreciated. Also if you can let me know of some steps it would be great.
Before doing anything backup your reporting services database and keys.
I would advice you to backup / restore the database to the new server rather than copying the mdf and ldf files. (report service must be stopped before restoring)
You should also export the encyption key from the old server and import it to the new server.
Also make sure to make the same customizations to the new report server configuration files if there are any (eg. custom dll permissions), copy custom dll's etc
By following the above steps you can make an SSRS database work on newer SSRS versions (I have tested restore an SSRS 2005 database to SSRS 2014 and 2016)
Read more:
https://learn.microsoft.com/en-us/sql/reporting-services/report-server/moving-the-report-server-databases-to-another-computer-ssrs-native-mode
Related
I am really new to this so please forgive this question.
We have sql server express 2008 running on a server which forms the back end database to a Access project (apd) application that sits on numerous client machines where user logins are controlled by usernames and passwords.
We need to decommission the server and are looking to transfer the database onto a new machine and then change the client app to point to the new server.
We think we've sorted the re-pointing issue but need some help on how to transfer the database "lock, stock and barrel" to the new machine running sql server express as well.
Any advice would be gratefully received. Thanks in advance.
Harv
Install Sql Server 2008 Express on the new server
Make sure you can connect to it from SSMS from outside of the server
On the old server, backup your database do a .bak file (you can do this from SSMS, right click on your database)
Move the .bak file to the file system of the new server
In SSMS, restore the new database (right click server name -> restore)
Update Sql Server user-access permissions so that your connection-string user has proper access to that database
Update the relevant connection strings in your application to refer to the new database server (IP address change? server name change? etc)
I'm trying to upgrade a database from a SQL Server 2000 instance to a SQL Server 2008 instance. I'm doing this by right clicking on the database and selecting copy database. My current issue is that I'm getting this error in the log file:
OnError,AQUE-SQLDEV,NT
AUTHORITY\SYSTEM,aque-db2000_aque-sqldev_sql2008_Transfer Objects
Task,{F0ACDE4D-D023-400C-BE3C-91CD3A537988},{40E67169-0F3F-4F86-AD2E-6E2CB532BA5C},18/10/2011
15:38:37,18/10/2011 15:38:37,0,0x,Script failed for User 'WebUser'.
StackTrace: at
Microsoft.SqlServer.Management.Smo.Scripter.ScriptWithList(DependencyCollection
depList, SqlSmoObject[] objects) at
Microsoft.SqlServer.Management.Smo.Scripter.ScriptWithList(SqlSmoObject[]
objects) at
Microsoft.SqlServer.Management.Smo.Transfer.Microsoft.SqlServer.Management.Common.ITransferMetadataProvider.SaveMetadata()
at
Microsoft.SqlServer.Management.Dts.DtsTransferProvider.Configure(ITransferMetadataProvider
metadataProvider) at
Microsoft.SqlServer.Management.Smo.Transfer.GetTransferProvider()
at Microsoft.SqlServer.Management.Smo.Transfer.TransferData() at
Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()
InnerException-->Creating a user without an associated login is not
supported in SQL Server 2008.;
Does anyone know why this might be happening?
Thanks,
Sachin
Based on the error it sounds like you need to create a login first on the SQL 2008 server that matches the same login/user that exists on the SQL 2000 server. You could do a couple of things:
create a new database in 2008 to migrate to
create a new login in 2008 that matches the existing login from sql 2000
map the new login to that new database from step #1
run the copy database wizard
If it was me, I would do as marc_s suggested and perform a full backup of the existing database on sql 2000, then restore to a blank database in sql 2008. If you can, update the compatibility mode in database properties to be 2008. I've done this hundreds of times and works like a charm.
The reason can be that a file with the new Database name already exist on the filesystem. We encountered this when we renamed Database X to X_Old, and tried to copy database Y to X. This cannot be done, because database X_Old is still associated with the filename X.
Either delete the conflicting database, or rename the file on the file system.
See http://codecopy.wordpress.com/2012/01/03/error-while-copying-a-database/
I would like to copy a database (tables, it’s data, stored procs & views) from SQL Server 2008 database to SQL Server Express. Is it possible? If so, would you please let me know how to do it? When I tried, it is giving some error.
Please note that I have only few records in SQL Server 2008 database tables.
Thanks and Regards..
Shruthi Keerthi..
The quickest way is to "detach" the source database from its server, copy the (2) files to a new name/location and (re)attach each database to the appropriate server.
Attach/detach is available as a command or via the SQL Visual Studio.
You can create a backup of the database and them restore that backup into the Express instance.
Another option, since you said you didn't have very many records in the DB, is to generate the SQL statements (right click on the database --> tasks -> generate scripts) and then run that on the Express instance. Then just copy over the tuples you want.
I prefer to use Backup/Restore when moving a database from one server to another. As long as your SQL Server and SQL Express are the same version, or the one you are moving to is newer than the one you are moving from (SQL 2005 to SQL Express 2008), it should work without a hitch.
If copying the entire database, I usually find it easiest to stop the source service, copy the *.mdf file to the appropriate new data directory, and just mount the MDF in the new service. As long as there aren't any changes in the setup (like FILESHARE), then this is the easiest way to clone a database.
And yes, this is possible. I just did this earlier today.
You could also try using the Microsoft Database Publishing Wizard.
It's simple to use and will create a SQL script that you can run to rebuild tables (including data), stored procs, views, etc...
You can download it here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=56E5B1C5-BF17-42E0-A410-371A838E570A&displaylang=en
I have a SQL Server 2008 database that is hosted by a third party host (heart internet).
How would I go about backing this up?
I used SQL Server Management Studio Express 2008 to create the tables within the database, but the backup options within this app seem to be only of use if you have direct access to the server machine (which I don't)
It's also worth noting that I am using change tracking - I presume this data would be lost should any backup be restored?
Thanks In Advance!
(PS - SQL Server 2008 novice here!)
If they allow you to run backups to a particular folder that you have access to you can just do it with the regular backup command:
backup database dbname to disk = 'y:\users\YourHomePath'
If they do not do that you might want to use the Database Publishing Wizard to script out your database (depending on the size this might be very slow)
You can create a .DAT file into a shared disk and to download it through FTP.
This is a continuation of an earlier question I had about moving the databases for a MOSS 2007 installation from SQL 2000 to SQL 2005. Here's the URL for the original question: Migrating MOSS 2007 from SQL 2000 to SQL 2005
In my test environment, I've successfully moved the databases to the SQL 2005 test machine and things appear to be working fine. But, on the "Servers in Farm" page of the Central Admin | Operations, it still shows the old (i.e. SQL 2000) server as the Configuration Database Server. Also, it shows the old config database as being the Configuration Database. I know that the SQL2000 server and old config database (that are showing on this page) are NOT being used, because we've deactived the SQL instance in SQL2000.
I've tried "removing" the server, and get a message about "Uninstalling SharePoint products and technologies" being the better route. So, I disconnected from the test databases, uninstalled SharePoint from the test WFE server, and reinstalled it. That didn't do anything. Before uninstalling/reinstalling I also tried simply rerunning the SharePoint Configuration wizard, and that didn't do anything either.
Does anyone know how to update the Config Server and Config Database on the "Servers in Farm" page after having moved the Config and Content DBs? Is there something I'm missing or overlooking?
Thanks.
stsadm setconfigdb
?
stsadm -help setconfigdb
shows:
stsadm.exe -o setconfigdb
[-connect]
-databaseserver
[-databaseuser ]
[-databasepassword ]
[-databasename ]
[-hh]
[-adcreation]
[-addomain ]
[-adou ]
Also see Technet which says PSConfig has superseded stsadm.
Hey, I completely understand your issue. YOu have moved your configuration database from the previous sql server to the new sql server. Let me make one thing very clear on this post that a configuration database cannot be moved to another sql server.
Hence, you need to run psconfig and disconnect from the current farm. Run psconfig again and create a new server farm. Once that is done, create new web application/applications and then attach the site content database/databases back to them. This is the only way to get your farm restored properly with the new sql server.
The best way we have found to do this is to use a SQL client side or DNS alias for the SQL server so that you can easily move the SP databases to a new server and just update the alias to point to the new one. In your case you could try the steps below, server names have been changed to protect the innocent. In this scenario you will need to have the same instance name (or use default) and possibly the same port.
Turn off SharePoint services
Rename the old SQL server from SQL2000 to SQL2000OLD
Create a DNS CNAME record called SQL2000 that points to new server called SQL2005
Detach/attach or backup/restore all databases from SQL2000 to SQL2005
Ping SQL2000 on SharePoint server to make sure that it resolves to SQL2005 and if not then run "ipconfig /flushdns" and repeat test until it resolves to new server
Bring SharePoint services back up, should connect to new server using DNS alias