Clustering Gotchas

A couple of weeks ago my company clustered a SQL2005 install and I posted about the 6 core CPU issues that were experienced. This weekend we clustered a SQL2000 on SQL2003 environment. SQL2000 is end of life but we still use it until the financial guys approve our upgrades. So with one of our most critical servers running standalone we attempted the cluster.

This server had been clustered in the past under a design the previous DBA had created and sold using mountpoints. Mountpoints are not supported on SQL2000/Windows 2003 configurations. Timeout issues on the mountpoints caused the cluster to fail regularly.

The following issues and resolutions from this weekend are below, it was successful and within the outage window.
Temp and Tmp environment variables have spaces in the paths:
Microsoft sets the default location for the Temp and Tmp variables are in the folder of the current user. When installing SQL on a cluster this will cause the install to fail with a folder not found error. The folder exists but if the path has spaces the install fails. Change the environment variables to a path without spaces, I usually use c:\temp for both.

Timeout during install caused by multiple drives in the SQL cluster group;
Not sure what causes the timeout but to get around this issue move all physical drives, excluding those needed for the install to the Cluster group. Once the install is complete move them back to the SQL group. We have 20 drive resources in the SQL group, this was done to assist with EMC snapshots but that technology is not currently being used.

Clustering in SQL2000 is a far easier task than was SQL7.0. SQL2005 continues the improvement and hopefully so will SQL2008. As tasks become more and more straight forward DBAs will have to distinguish themselves by the other talents needed to excel. Performance tuning, database design etc. The administrative tasks will always be needed, but at least at my company, it takes more than just normal admin skills to succeed.