Or use SQL Server aliases (configure in the SQL Server client) instead of CNAMEs
Update the (local) alias on the SQL Server after renaming (if this is still required for SQL Server 2008 R2) Cheers Ken From: [email protected] [mailto:[email protected]] On Behalf Of Sean Martin Sent: Tuesday, 13 August 2013 6:39 AM To: [email protected] Subject: Re: [NTSysADM] sql server upgrade I agree with everyone else, go with option 2. Might be a good time to research the possibility of updating all of your client ODBC connections to reference the DB by cname rather than server name. - Sean On Mon, Aug 12, 2013 at 12:10 PM, Christopher Bodnar <[email protected]<mailto:[email protected]>> wrote: Agree with others that #2 is the best option. Not sure how many or how complicated your maintenance plans are, but if it's worth your effort, this might help in the migration: http://www.symantec.com/connect/articles/progress-creating-and-managing-sql-server-database-maintenance-plan Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459<tel:610-807-6459> 3900 Burgess Place, Bethlehem, PA 18017 [email protected]<mailto:[email protected]> [cid:[email protected]] The Guardian Life Insurance Company of America www.guardianlife.com<http://www.guardianlife.com/> From: Jesse Rink <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: 08/12/2013 03:37 PM Subject: [NTSysADM] sql server upgrade Sent by: [email protected]<mailto:[email protected]> ________________________________ We have an older Windows 2003 R2 x64 VM server which contains SQL2005 x64 on it. I'm planning on getting this box more current... My first option is to: 1. Take a image backup of the VM with our PHD Virtual software 2. Increase the c: drive hard disk in vSphere and then use a partition tool to expand the c: partition (its too small to perform the 2008 R2 upgrade on it) 3. Upgrade 2003 R2 x64 to Windows 2008 R2. 4. Upgrade SQL 2005 to SQL 2008 R2. Anyone had bad experiences going this route? The second option is to: 1. Create a brand new 2008 R2 server with SQL 2008 R2. 2. Detach the 10 DBs from SQL-OLD, copy them over to the SQL-NEW server and re-attach. 3. Decomission the old SQL-OLD server 4. Rename SQL-NEW to SQL-OLD and assign it the same IP address that the original SQL-OLD had. 5. Setup my Maintenance Plans from scratch. I think I'll be good for all my client applications that have specific ODBC settings configured pointing to either the IP address of the SQL box or the computer name/FQDN. Anyone had bad experiences going this route? Leaning more towards option TWO at this time... I tend to like clean installs as opposed to upgrades (generally). JR ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you.
<<inline: image001.jpg>>
