June 23, 2011 at 8:11 am
Hi we are planning to move our SQL Server default instance (only instance running) to another machine as an upgrade.
I don't want to lose my SQL logins and Agent jobs and was wondering if it's as simple as detaching and attaching the system databases (like master, msdb, model, tempdb) .
If there are any articles on SQL Server Central, that'll be helpful too. Thanks!
old machine had Windows 2003 R2 Enterprise x86 OS and SQL Server 2008 R2 Enterprise x86
new machine is Windows 2008 R2 x64 and SQL Server 2008 R2 Enterprise x64
Both Intel Xeon platforms
June 23, 2011 at 8:40 am
I've had mixed results when it comes to restoring system databases. Lately I've given up on that and used a few other methods to make migrating/consolidating servers easier.
I have used this KB for moving logins (SQL and Domain) between servers and it has worked quite well. I don't need to know the passwords because it uses the password hash to recreate the accounts, and it uses the same login SIDs so there is less account cleanup afterwards.
http://support.microsoft.com/kb/918992
I usually use SSIS to move jobs between servers, although it won't clean up any server-specific calls. I highly recommend going through each job to check for those.
June 23, 2011 at 9:12 am
you can restore the msdb database but it can quickly become messy.
I would definitely advise against it if you use maintenance plans unless you delete them before the move,
If you use proxies these will need recreating which will mean dropping and recreating jobs.
If SSIS packages are stored in msdb they should use some for of external configuration for the server connections.
If service broker is enabled this will need disabling and re-enabling.
So I would only restore msdb if you have a LOT of SSIS packages which don't need altering for a change in server name.
---------------------------------------------------------------------
June 23, 2011 at 9:23 am
george sibbald (6/23/2011)
you can restore the msdb database but it can quickly become messy.I would definitely advise against it if you use maintenance plans unless you delete them before the move,
If you use proxies these will need recreating which will mean dropping and recreating jobs.
If SSIS packages are stored in msdb they should use some for of external configuration for the server connections.
If service broker is enabled this will need disabling and re-enabling.
So I would only restore msdb if you have a LOT of SSIS packages which don't need altering for a change in server name.
Thanks guys. We don't have any SSIS packages on this server.
I do have maintenance plans.
My main concern is making sure the users and sql agent jobs are moved correctly.
I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks
June 23, 2011 at 9:35 am
I do have maintenance plans.
My main concern is making sure the users and sql agent jobs are moved correctly.
I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks
that would be your best bet. Remember though maintenance plans create jobs, do not script those out and copy over, these are best recreated from scratch I am afraid.
---------------------------------------------------------------------
June 23, 2011 at 9:35 am
master.dbo (6/23/2011)
george sibbald (6/23/2011)
We don't have any SSIS packages on this server.
I do have maintenance plans.
My main concern is making sure the users and sql agent jobs are moved correctly.
I guess for the sql agent jobs, instead of moving msdb I can just script the jobs correct? thanks
You can create scripts for the Maintenance Plans, Jobs, Logins and Users and execute them on the Destination Server.
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply