May 26, 2013 at 11:27 pm
Hi All,
I'm tasked with moving an existing SQL Server 2008 R2 environment to a new server. The current server is attached to a SAN. The SAN is staying the same...it's going to be detached and attached to the new Server. All system databases are on the M drive (the san). So...all that will be changing is the server. I've come up with the following plan...just wanted to check with you all if this is correct:
1. Create new server and ensure SQL and Patch are same level as existing server.
2. Detach SAN and reattach to new server
3. Ensure new server can see SAN drives
4. Switch off old server. Change server name on new server to the name of the old server
5. Change startup parameters for MASTER db and point to M drive
6. Alter MSDB database and also point to M drive
7. Configure TEMPDB (split into multiple files)
This seems straight forward...but I'm not too sure
Thanks
Denesh
May 28, 2013 at 5:08 am
I would say there are a lot of things you need to take into conideration still:
- If you are renaming a server that hosts SQL Server you will need to go through certain steps to ensure the SQL Server instance reflects this change:
How to: Rename a Computer that Hosts a Stand-Alone Instance of SQL Server
Additionally you should probably research the following on the current instance to ensure they get migrated over:
- logins (which do not get migrated over like users do)
- SQL Agent jobs
- Linked servers
- Stored credentials
- Maintenance Plans
- SSIS packages
- Certificates
Joie Andrew
"Since 1982"
May 28, 2013 at 9:11 am
If you really want to do it like you detailed then ensuring the same patch level is essential, however you will definitely have issues with encryption using the SMK which will be orphaned and will need re generating. IMHO it's best to build a new instance and move the user databases and other objects.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
May 28, 2013 at 10:06 pm
Hi guys,
Thanks for the replies.
This environments has no certificates.
Regarding the maintenance plans, logins etc...by moving the current Master and Msbd...this should be covered.
There also no Smk being used.
Thanks again guys for the reply
May 29, 2013 at 2:41 am
Are the paths that SQL Server is installed in the same between the old and new instance? If not I would imagine you are going to have problems with where master is pointing for certain resources.
Joie Andrew
"Since 1982"
May 29, 2013 at 7:20 am
Test your intended process using a sandbox server before doing it with real data. This will help you find anything you have missed.
My personal preferance is to build a new server and move over the logins, etc followed by the user databases. If anything goes wrong then doing it this way means there is a standard build and standard troubleshooting can be used.
Doing it your way means ther will be far less help available if you need to troubleshoot. You should factor in the relative risks before deciding what approach you will use.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 29, 2013 at 7:55 am
Hi all
Yes the install paths will be the same.
This plan will be tested first on a qa server.
The reason for this plan is to ensure migration is as seamless as possible. Therefore I want to use the existing Master db on the new server so as to not miss anything.
Also downtime for this environment is very limited.
May 30, 2013 at 8:13 am
You may or may not also want to alter this to in "change IP address of old server to newly assigned IP, change IP address of new server to be that of what the old server had been running as" prior to powered off the old server. This avoids the host file edits proposed above, and also accounts for hardcoded IP address connections (not uncommon if your environment has had DNS issues before).
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply