Hi all,

I have been tasked with migrating our SQL Server 05 Active/Passive cluster from 32bit to 64bit with as little downtime as possible.   What is the best method of this.  Can I just build one node and swap it out having a 32bit node and 64bit node attached or do I have to build both nodes and just reattach/restore the databases after the cluster is built?

A big task in little time, impossible without performing proper testing.

All instances of SQL Server participating in a Cluster must be the same -either 32 bit or 64 bit.

However, you may want to consider running 32 bit SQL Server on the 64 bit Windows Server.

Or, you may forgo the Cluster, and using the 64 bit SQL Server as primary, create a Mirror server with the 32 bit server as a fail-over partner.

http://technet.microsoft.com/en-us/library/ms143393.aspx

http://technet.microsoft.com/en-us/library/ms191295.aspx

http://technet.microsoft.com/en-us/library/ms144267.aspx

http://www.sql-server-performance.com/articles/clustering/upgrade_current_cluster_p1.aspx

All the above links should give more information on the steps and things to take care.

Thanks sayta.  Little downtime doesn't mean a short amount of time, but rather with as little interruption in database service access.  We only have 1 shared set of drives so since you said I can't mix 32 and 64 the upgrade will have to wait.  However, I am curious since I have never dealt with SQL Server on 64bit platform, other and memory addressing is there really a noticeable difference in migrating and if so where is the biggest increases in performance?  I have been unable to find a reliable comparison for the 2.

Thanks, 

 I just did this very thing. I was tasked with getting our existing 32 Bit 2000 Production Cluster up to SQL Server 2005 64 bit. I was given very little time to prepare, no environment to test in, a 3 day maintenance window and very little chance of success.

 The thing is, not only can you not mix 32 and 64 in a cluster but, you have to have both nodes up and the cluster configured to do a SQL server 2005 cluster install. Well, you don't HAVE to I suppose but, it's not the MS supported method.

I succeeded it took approximately 2.5 days, I took my time and got sleep. You might be able to do it sooner. I would also set management's expectation level for one of utter and complete total failure if you are given lack of time to prepare and test as I was. Below is my experience and the general steps involved.

Prep: Read The SQL Server 2005 Upgrade Handbook, SQL Server 2005 Security Best Practices - Operational and Administrative Tasks, and most importantly SQL Server 2005 Failover Clustering White Paper. Run SQL Server 2005 Upgrade Advisor Make note of the results, deal with the things it tells you too.

One the day of your upgrade:

1) Say a little Prayer 

2) Make Backups of your databases and servers.

3) Extract SQL Accounts

4) Migrate DTS Packages  (in My case) from 2000 to 2005 instance on a Laptop using SQL 2005 developer Edition and the DTS Migration Wizard.

5) Extract SQL Agent Jobs

6) Make notes of or extract DDL for DB Links, ODBC Sources, Etc. You can extract ODBC Sources by exporting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI

7) Detach The databases (ones that will be migrated).

8) Take a Deep Breath.

9) Shut Down your existing Cluster

10) Blow away existing cluster and install Windows 2003 x64. Apply SP2, get Updates, Update firmware and drivers for hardware.

11) Create and test your cluster.
     11a) Make sure your Heartbeat is setup correctly.

12) Install SQL Server 2005 x64 on your Cluster,  Make sure you also install things like SSIS and MS to the inactive node also, they aren't done for you.

13) apply SP2

14) Attach Databases

15) Restore Accounts, ODBC, Jobs, Links, etc.

16) Use Package Migration wizard to move packages over from were they were put earlier. 

17) ReIndex and Update Statistics.

 That was about the gist of it. The cluster just had it's first week of full production load and is doing very well. Yes, there is a noticeable difference I have seen in watching perfmon. CPU is lower, I/O is a tad Faster, page file usage is at 0%, cahe hit ratio at 99%+.

Good Luck.
 

Ziptar

Appreciate your feedback in this regard, not every user would do the same. I'm going to put up this as a sticky post for further reference.

Thanks.

No problem, took me quite a bit of time and study to put all the parts together and the whole process is pretty scary to boot.
 

Just wanted to say thanks again to Ziptar. I'm getting ready for similar move in the next week or two (except I have the benefit of going to a new cluster, so I'm lucky to have a fall back should problems arise), and this thread has been a huge benefit to my preparation. Thanks to everyone who posted links to relevant info as well!