2 Cluster Node 32 bit to 2 Cluster Node 64 bit | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

2 Cluster Node 32 bit to 2 Cluster Node 64 bit

Hello, I’m trying to gather some information on what it will take to bring in two 64 bit servers to replace our 32 bit Servers. We have Active Passive two node setup currently with the following. Software is SQL 2000 Enterprise Service Pack 3a. Our current hardware is Windows Server 2003 Enterprise CPU 3.06 GHZ and 7.73 RAM. We have 3 instances on our active node. Each instance has serveral databases. Will this require downtime? What is the preferred methodology. What type of testing needs to take place? -Thank you
You’ll have to upgrade to SQL2005 first. There is no x64 for SQL2000, only IA64 (Itanium) exists if you want into the 64-bit world for SQL2000. Once over that hurdle, build your new cluster and install the SQL Server. Then do a backup & restore to move the databases to the new cluster. Downtime is involved no matter what with a complete server to server migration. If you have a SAN with BCV/Snap functionality you can dramatically reduce the downtime required as the SAN can generate BCV’s/Snapshots much faster than a backup & restore can move the data…
I have a follow up question to your response. Haywood mentioned taht when configuring your new cluster and installing SQL the only thing that needs to happen is the backup and restore to move the new databases to the cluster. Just to verify, would the new cluster maintain the same instance names as the prevoius clustered server that was on the 32bit servrs or would the new cluster have to have a new instance name. I’m trying to get an idea of if there would be a need for the developers to be involved changing the database connections on the application servers. Please advise, Thanks again.
It would have new instance names, you cannot duplicate them on a network. Once the new system is up and everything/one has been migrated, you can create a CNAME entry of the old server and point it to the new. This is quite a common technique, but gets cumbersome after several full hardware migrations (you end up carrying over names).
Haywood, Thanks for the reply. I have one final question. I’m trying to figure out a good strategy for moving towards our goal of having our instances up and running in 2007 with the new 64 bit Servers. From your previous comment I see that we will need to migrate each of the databases(backup then restore) to their new instances on the 64 bit servers. Given that the new 64 bit Severs will be loaded with SQL 2005 Enterprise(64 bit Edition), would it be beneficial to just migrate our existing SQL 2000 databases by doing a backup and restore once the new 64 bit servers are in place. It was my understanding that the new 64 bit version will run the 32 bit applications in Legacy mode. Is this true or am I missing something? This would reduce the need to go thru an upgrade to 2005 on our existing prod cluster and thus reduce time taking for developers to test their application twice. Is this true or do we have to follow the course of upgrading or migrating to 2005 first. (see path 1 or 2 below) Path 1
a)Apply Service Pack 4 to our existing Production Cluster. (Resouces for testing)
b)Migrate or Upgrade the current Production Cluster to SQL 2005.(Resources for testing)
c)Configure the new 64 bit servers and load the 64 bit SQL software
d)Migrate the databases to the new production cluster. (Resources for testing)
e)Discontinue the old production cluster.
Path 2
a)Configure the new 64 bit servers and load the 64 bit SQL software
b) Migrate the database to the new production cluster. (Resources for testing)
One follow up note: It was my understanding that vendor software and developer applications running 32 bit applictions would be compatible and work withiout issues in the new 64 bit platform. Is this true?
Thanks again.
]]>