SQL SAN Migration

Question

I have a clustered installation of SQL 2000 on an Itanium based server, the DB's are on a SAN disk. I need to move the DB's onto a new cluster which is Intel x64 as the existing servers are end of life.  I need to retain the old virtual hostname on the new cluster.

My SAN specialist has advised he can move the DB's in bulk by transferring the SAN disk to the new cluster nodes, however I have concerns about the success of this method.

The plan is once the DB's are moved to the new SAN/cluster they are upgraded to SQL2K5/8

Is it possible to move the databases using this method?
What is the best method of moving a large number of DB's to a new cluster?
Can I add new x64 servers to a x64 Itanium cluster? (I was told this may not be possible)

Answer 1

Hi Tufty

There are a few things here:

1. You cannot have a mixed-architecture cluster, so no x64/Itanium mixtures are allowed.

2. You can (relatively easily) move the databases using the SAN migration method if the target architecture is the same - same SQL Version and SP, keeping the server names etc. However, since you are moving to a new architecture, there are potential difficulties.

Now, the database files are agnostic about the binaries used - they don't care whether the server is x86/x64 or Itanium. The only thing I would be cautious about is the restore of the system databases - master and msdb in particular. Though it may be that this will not be an issue.

The safest way is to script your system objects (logins, linked servers and scheduled jobs etc), backup your databases. Shut down your old server. Remove the AD objects. Build your new cluster (SQL2005 or SQL2008) with the same name, script in your system objects, restore your databases. Then upgrade your databases - update stats, DBCC, rebuild indexes change compatability level, page-verify mode etc

This has the added advantage of achieving the migration and upgrade in one step. More complex big-bang approach admittedly.

HTH

Ewan

---

If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.

Answer 2

Hi Tufty

There are a few things here:

1. You cannot have a mixed-architecture cluster, so no x64/Itanium mixtures are allowed.

2. You can (relatively easily) move the databases using the SAN migration method if the target architecture is the same - same SQL Version and SP, keeping the server names etc. However, since you are moving to a new architecture, there are potential difficulties.

Now, the database files are agnostic about the binaries used - they don't care whether the server is x86/x64 or Itanium. The only thing I would be cautious about is the restore of the system databases - master and msdb in particular. Though it may be that this will not be an issue.

The safest way is to script your system objects (logins, linked servers and scheduled jobs etc), backup your databases. Shut down your old server. Remove the AD objects. Build your new cluster (SQL2005 or SQL2008) with the same name, script in your system objects, restore your databases. Then upgrade your databases - update stats, DBCC, rebuild indexes change compatability level, page-verify mode etc

This has the added advantage of achieving the migration and upgrade in one step. More complex big-bang approach admittedly.

HTH

Ewan

---

If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.

If your user databases are on a cluster resource disk, you can move that disk to the new cluster and bring it into the new clusters resource group and then attach the user databases to the instance.  You have to be careful doing this because once you do, there is not going backwards with the databases since they are upgraded internally when they first attach to 2005/2008.  Make sure that you have a functional backup of the databases before trying this.  You can't restore the system databases from 2000 onto 2005 or 2008, or to an installation of SQL that is on a different build number than the build that the databases came from.  You would have to script your logins/jobs/DTS packages/etc from the old server and create them on the new one.  The virtual host name information is a DNS entry, so you can easily go back and update DNS and AD so that your new cluster has the old name, post installation of the new cluster.  If it were me and I had the SAN space and ability to schedule downtime, I would:

1. Build the new windows cluster
2. Install the SQL Binaries
3. Validate the cluster configuration and test failover
4. Transfer Logins, Jobs, and DTS Packages as necessary to the new cluster following: Transfer Logins to Another Server or Transfer Jobs and Logins using SSIS
5. Transfer a copy of the databases onto the new cluster for testing.
6. Once testing is complete plan your migration following: http://www.sqlservercentral.com/articles/Backup+%2f+Restore/66962/
7. At cut over, restore the tail log, and change the cluster name to what you need following: http://msdn.microsoft.com/en-us/library/ms178083.aspx

This would minimize downtime and keep things like you want in the end, and it would allow you to rapidly fall back on your 2000 cluster if there is a problem.

---

Jonathan Kehayias
http://sqlblog.com/blogs/jonathan_kehayias/
http://www.twitter.com/SQLSarg
http://www.sqlclr.net/
Please click the Mark as Answer button if a post solves your problem!