SQL Server 7.0 Clustering
Tip: To change any of the SQL Server service accounts on a clustered SQL Server 7.0 cluster, you must uncluster, the recluster your SQL Servers.
Explanation: Here’s how to properly change the service accounts when SQL Server 7.0 is clustered.
First, ensure that the node that SQL Server was initially installed on in the cluster is the active node.
Second, remove the SQL Server virtual server by running the Cluster Failover Wizard.
Third, change the SQL Server service accounts as needed.
Fourth, reinstall the SQL Server virtual server by running the Cluster Failover Wizard.
Date Added: 10-17-2001
Tip: Don’t use virus checking software on your cluster. It not only makes your SQL Server cluster more unreliable, it hurts performance.
Explanation: Although, technically speaking, if your virus software claims to be cluster compatible, virus software can run on a cluster, although it is not recommended. Research has shown that high availability clusters are more highly available without virus software than they are with it. In addition, virus software chews up valuable CPU cycles and memory that can better be used by SQL Server for optimum performance.
One way to avoid viruses on a SQL Server is to ensure that any computer, client or otherwise that connects to the SQL Server cluster, has virus software on them. A second way is to ensure that your clustered SQL Server does not have any e-mail packages on it. A third way is not to browse the web from a clustered SQL Server. And a forth way is to not have any shared folders on the cluster.
Version: 7.0, 2000
Date Added: 12-11-2001
Tip: Do not install MDAC versions 2.6 or 2.7, or any of it service packs, on a SQL Server 7.0 cluster.
Explanation: Microsoft does not support, nor does it appear it will ever support, MDAC versions 2.6 or 2.7, and its service packs, on SQL Server 7.0 clustered servers. If you do install it, SQL Server 7.0 clustering will fail and you will have no choice but to reinstall both the operating system, clustering services, and SQL Server 7.0 clustering.
Date Added: 12-28-2001
Tip: When any SQL Server administrative tools, such as Enterprise Manager, Query Analyzer, and Profiler, is performing some task, and a SQL Server failover occurs, the current process will stop and have to restarted once the failover is complete.
Explanation: SQL Server administrative tools, just like any software connected to a SQL Server cluster, will fail when failover occurs. This means that any task or process you were running (such as a SQL Server backup job) will fail, and will have to be restarted once the failover has completed. In some cases, you may want to close the software, then restart it, so that you are properly authenticated on the new server before you restart any tasks.
Version: 7.0, 2000
Date Added: 1-25-2002
Tip: SQL Server clustering is not designed to prevent data failure. For optimum data protection, consider using log shipping to move data from your production cluster to another SQL Server, preferably off-site.
Explanation: While SQL Server clustering can provide fault tolerance for many aspects of a SQL Server, such as hardware, network, operating system, and application failure, it cannot protect against lost of data. This includes if the shared array fails, the connections to the shared array fails, if data is destroyed by users by accident, or if the entire cluster is destroyed.
While nightly backups are important, they still leave a lot of data unprotected. If your cluster must have very high availability, consider using log shipping (either built into SQL Server 2000, or a version that you perform yourself) to move data to another server, preferably to a server located offsite, and connected to your cluster via a WAN or high-speed LAN. This of course entails making the necessary preparations to move to the other server should the cluster fail.
Version: 7.0, 2000
Date Added: 2-5-2002