SQL Server Q&A

Symptoms
This article describes the Microsoft support policy for SQL Server failover clustering. Microsoft Customer Support Services (CSS) supports SQL Server failover clustering that is based on the failover clustering features of the Microsoft Cluster Service in the following products: Windows 2000 Advanced ServerWindows 2000 Datacenter EditionWindows Server 2003 Enterprise EditionWindows Server 2003 Datacenter EditionWindows Server 2008 Enterprise EditionNote Windows Server 2008 failover clusters only support SQL Server 2005 Service Pack 2 or later versions.
Important Upgrading SQL Server 2000 Enterprise Edition to SQL Server 2005 Standard Edition is not a supported upgrade path. For more information, visit the following Microsoft Developer Network (MSDN) Web site:
http://msdn2.microsoft.com/en-us/library/ms143393.aspx(http://msdn2.microsoft.com/en-us/library/ms143393.aspx) If you want a fallback solution when you upgrade the SQL Server 2000 failover cluster instance,we recommend that you perform a new installation of the SQL Server 2005 failover cluster instance because ofextreme recovery measures. Then, migrate the data to the new installation. The current installation will remain intact if unforeseen circumstances prevent the SQL Server 2005 installation from completing in a timely manner.
Microsoft server clusters are only supported on cluster solutions that are listed in the Windows Server Catalog under Cluster Solutions. To view the Windows Server Catalog, visit the following Microsoft Web site:
http://www.windowsservercatalog.com/(http://www.windowsservercatalog.com/)The term “server clusters” means computers that run the Microsoft Cluster Service. The Windows Server 2003 family provides the following types of clustering services: Server Cluster (Failover Cluster) Network Load BalancingCompute Cluster ServerOnly the Server Cluster solutions can be used together with SQL Server for high availability if a node is lost or if a problem exists with an instance of SQL Server. Network Load Balancing may be used in some cases together with stand-alone read-only SQL Server installations. SQL Server Failover Clustered Instances each require a unique group. This requirement is true on cluster disk resources that use drive letters that are unique to the cluster and to each SQL Server Failover Clustered Instance. Each Failover Clustered Instance of SQL Servermust also have at least one unique IP address. Depending on the version that is installed, multiple unique IP addresses may be possible. Additionally, each Failover Clustered Instance must have both virtual server and instance names that are unique to the domain to which the cluster belongs.
Supported SQL Server failover clustering installations must also follow the Microsoft support policy for server clusters, and the Windows Server Catalog/Hardware Compatibility List.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
309395?(http://support.microsoft.com/kb/309395/) The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server CatalogStarting with Windows Server 2003, Microsoft SQL Server 6.5 and Microsoft SQL Server 7.0 clustering will no longer be supported, as noted in the following Microsoft Knowledge Base article:
810391?(http://support.microsoft.com/kb/810391/) SQL Server 6.5, SQL Server 7.0, and MSDE 1.0 support on Windows Server 2003If you cluster SQL Server with any clustering product other than Microsoft Server Clustering, your primary support contact is the third-party cluster solution provider for any support issues that are related to SQL Server. SQL Server was developed and tested by using Microsoft Server Clustering. Third-party clustering solutions that support SQL Server installations should be your primary contact for any installation issues, performance issues, or cluster behavior issues. CSS provides commercially reasonable support for third-party cluster installations in same manner that we do for a stand-alone version of SQL Server.Number of supported nodesThe following is a list of the number of nodes that are supported by each version of Microsoft SQL Server: Microsoft SQL Server 7.0
Microsoft SQL Server 7.0 supports up to two nodes in a failover cluster.Microsoft SQL Server 2000 Enterprise Edition (32-bit)
Microsoft SQL Server 2000 Enterprise Edition (32-bit) supports up to four nodes in a failover cluster.Microsoft SQL Server Enterprise Edition (64-bit)
Microsoft SQL Server Enterprise Edition (64-bit) supports up to eight nodes in a failover cluster.Microsoft SQL Server 2005 Standard Edition (32-bit or 64-bit)
Microsoft SQL Server 2005 Standard Edition supports up to two nodes in a failover cluster.Microsoft SQL Server 2005 Enterprise Edition (32-bit or 64-bit)
Microsoft SQL Server 2005 Enterprise Edition supports up to eight nodes in a failover cluster.Note If you upgrade Microsoft SQL Server 2000 (32-bit) to Microsoft SQL Server Enterprise Edition (64-bit), SQL Server will still only support four nodes.Mounted drivesThe use of mounted drives is not supported on a cluster that includes a Microsoft SQL Server installation. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
819546?(http://support.microsoft.com/kb/819546/) SQL Server 2000 and SQL Server 2005 support for mounted volumes
Note SQL Server 2005 failover cluster instances are not supported on failover cluster instance nodes that are used as domain controllers.
Resolution
SQL Server failover clustering for clusters that are not listed on the HCL in the cluster categoryIf your SQL Server failover cluster solution is not listed in the Windows Server Catalog/Hardware Compatibility List. as a supported “Cluster Solution”, it is considered unsupported and may yield unexpected behavior. However, CSS will offer troubleshooting tips and provide reasonable support if requested. However, CSS does not guarantee that a resolution will be found for non-Windows Server Catalog/HCL cluster solutions.
For support, follow these steps: Before any troubleshooting begins, you must contact the Original Equipment Manufacturer (OEM) to discuss whether your particular cluster implementation is supportable. The OEM can best answer configuration and supportability questions for the cluster hardware.Upon agreement that no solution is guaranteed, and that no incident refund will be provided, CSS can troubleshoot the issue. Microsoft does not guarantee a solution with non-HCL clusters. If no resolution is found, the incident will not be refunded.
If it is not agreed that a solution is not guaranteed, CSS will not troubleshoot the issue and will refund the incident.CSS will use standard troubleshooting processes to isolate the server cluster issue. Some typical troubleshooting methods that are used by CSS include: Use of the Microsoft Knowledge Base. The Microsoft Knowledge Base is available to customers through Microsoft TechNet, or you can visit the following Microsoft Web site:
http://support.microsoft.com(http://support.microsoft.com/)Determine whether the problem can be replicated on supported clusters (where possible).Note If the cluster is not certified, there is no hotfix support available. CSS cannot determine whether the problem is caused by hardware incompatibility or by unwanted software behavior.If there is no solution to the problem, CSS may recommend some constructive alternatives, which include: Having you reproduce the problem on a cluster that is on the Cluster HCL.Asking you to use a cluster solution that is on the Cluster HCL.Having you work with the OEM to get the cluster on the Cluster HCL.Asking you to work with the OEM for a solution. The hardware specifications for server clusters are extremely stringent. The Cluster HCL contains a list of known acceptable cluster configurations that have been tested. You can waste a lot of time by trying to troubleshoot perceived server cluster issues that are being caused by the cluster hardware that you are using.
Some examples of hardware incompatibilities that can cause cluster problems include: SQL Server Failover Clustering installation failures.The cluster solution does not correctly isolate the shared disk and host bus adapters (HBAs) from other devices on the shared bus.The SCSI controller does not support operating in a multiple-initiator environment.The HBA does not correctly handle reservations or release or renew a device on the shared bus.The caching mechanism on the controller is incompatible with the cluster configuration.The network adapters for intra-cluster communication have too high a latency.The RAID controller does not correctly replicate configuration information between controllers.The PCI bus is incorrectly configured and has incorrect adapters in the wrong bus (primary, secondary, tertiary).The controllers are incompatible with the “Physical Disk Resource” type.The SCSI controller does not deploy proper termination. This list does not include all the issues that can cause problems with a server cluster. None of these issues can be detected by CSS. All these issues would typically be discovered if the complete cluster solution were tested for Cluster HCL compatibility.
If a complete cluster configuration is listed for an earlier operating system but is not listed for the newer operating system that you are using, support as documented in this section will be followed.
SQL Server 2005 support for mixed 32-bit and 64-bit SQL Server failover cluster instancesYou must be running Windows Server 2003 Service Pack 1 or a later version. For more information, see the following Microsoft Knowledge Base articles. For IA-64 installations, see the following article in the Microsoft Knowledge Base:
312090?(http://support.microsoft.com/kb/312090/) Cannot use 32-bit resources on a 64-bit server clusterFor X64 installations, see the following article in the Microsoft Knowledge Base:
875423?(http://support.microsoft.com/kb/875423/) Support for 32-bit programs on 64-bit server clusters is included in Windows Server 2003 Service Pack 1 and in x64-based versions of Windows Server 2003Warning Resource DLLs for 32-bit programs cannot run on a 64-bit computer that is running a 32-bit version of Windows Server 2003 without any service packs installed. Therefore, you cannot run 32-bit programs on a 64-bit server cluster. In this scenario, you must use a 64-bit version of the resource DLL.
Limitations of using mixed SQL Server 2000 and SQL Server 2005 failover cluster instancesWhen you use SQL Server 2000 installations and SQL Server 2005 installations on the same cluster, the SQL Server 2000 installations must be installed before you install SQL Server 2005 instances locally or as failover cluster instances. All failover cluster instances will use the SQL Server 2005 Server Cluster resource. This includes the instances of SQL Server 2000.
Additionally, after SQL Server 2005 is installed, SQL Server Native Client is the primary protocol that is used. The changes to the Server Cluster resource DLL and the primary protocol that is used will prevent installation of SQL Server 2000 or re-addition of nodes to SQL Server 2000 failover cluster instances. This occurs because neither the resource DLL nor the primary protocol existed at the time SQL Server 2000 was released and will not be recognized as a valid Server Cluster resource DLL or as a primary protocol for SQL Server failover cluster instances.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
905618?(http://support.microsoft.com/kb/905618/) You may receive a connection error message when you try to connect to an instance of SQL Server 2000 or of SQL Server 7.0 that was installed after you installed SQL Server 2005Stand-alone installations are not affected during initial installation like virtual failover cluster instances. In virtual failover cluster instances, this will prevent the initial installation from completing.
Note After you install SQL Server 2005, SQL Server Service Manager displays the node name instead of the virtual SQL Server 2005 server name. It does this because SQL Server Service Manager was not coded to handle SQL Server 2005, and SQL Server 2005 does not include SQL Server Service Manager.
Windows Server 2008 Failover ClustersOnly SQL Server 2005 Service Pack 2 (SP2) or later versions of SQL Server 2005 are supported with Windows Server 2008 Failover Clusters.
Migrating SQL Server Failover Cluster Instances to New Domain SQL Server 2000, 2005, and 2008 can be migrated to a new domain while clusterd is using domain users for service accounts on Windows 2000 and Windows 2003 Server Failover Clusters. SQL Server installations on Windows 2008 Failover Cluster will require uninstalling SQL Server Database Engine and Analysis Services if installed since Cluster will need to be uninstalled per
269196?(http://support.microsoft.com/kb/269196/) How to move a Windows Server cluster from one domain to anotherPrior to uninstalling SQL Server must be set to use mixed mode security or new domain accounts added to the SQL Server logins and the DATA folder containing system databases must be renamed prior to uninstalling so this folder may be swapped back in once reinstalled to reduce down time. No removal of SQL Server support files, SQL Server Native Client, Integration Services or Workstation Components should be done.

Symptoms
The purpose of this article is to help you in the setup or in the troubleshooting of a configuration for a COM+ Application Server or a configuration for an Internet Information Server (IIS) computer that interacts with a clustered server that uses Microsoft Cluster Server (MSCS) that is behind a firewall.
You may have one of the following scenarios: COM+ or IIS computer (client computer)SQL Server clustered that uses MSCSMicrosoft Distributed Transaction Coordinator (MSDTC) as a clustered resource in its own resource group (own name and IP address)Cluster and client computer that are separated by a firewall Certain Internet Protocol (IP) addresses and their corresponding network names must be known by the client computer for MSDTC to work correctly. The client computer can resolve the following names and the following IP addresses by using Domain Name System (DNS), hosts file, or another name resolution method: MSDTC resourceAn instance of SQL Server if the cluster configuration is either active-passive or active-activeCluster Name Certain IP addresses and their corresponding network names must be known by the nodes in the cluster for MSDTC to work correctly. Both nodes in the cluster can resolve the client computer name to an IP address by using DNS, hosts file, or another name resolution method.
Resolution
Additionally, the firewall must be configured to allow bidirectional traffic to occur between the client computer and the cluster. The firewall rules must include the following: The IP network names and the addresses of both physical nodes on the clusterThe SQL Server Instances network names and addressThe client network name and addressesThe child network name and IP resource of the MSDTC Resource Firewall rules must include the range of IP ports that are defined in the registry to allow traffic. See the “References” section.
You may also have to open an additional range of available IP ports as a requirement for the cluster server. See the “References” section for more information.

Symptoms
When you try to bring a SQL Server cluster resource online for a virtual instance of Microsoft SQL Server 2000, of SQL Server 2005, or of SQL Server 2008, you may notice the following behavior:The SQL Server cluster resource goes to a “failed” state and does not come online. You receive a combination of the following error messages on the computer that owns the SQL Server cluster resource.

Error message 1
An event that is similar to the following is in the system event log:

Date: 08/05/2004
Time: 1:11:19 AM
Source: ClusSvc
Category: Failover Mgr
Type: Error
Event ID: 1069
User: N/A
Computer: <Computer Name>
Description:
Cluster resource ‘SQL Server (<SQL Server instance name>)’ in Resource Group ‘<Cluster group name>’ failed.
Error message 2
An error message that is similar to the following is in the Cluster log file:

00000644.00000944::2003/11/30-18:11:30.360 SQL Server <SQLServer>: [sqsrvres] Unable to read the ‘VirtualServerName’ property. Error: d.
00000644.00000944::2003/11/30-18:11:30.360 SQL Server <SQLServer>: [sqsrvres] OnlineThread: Error d bringing resource online.
Error message 3
Error messages that are similar to the following are in the SQL Server error log file:

2003-11-30 17:00:37.27 server Error: 17826, Severity: 18, State: 1
2003-11-30 17:00:37.27 server Could not set up Net-Library ‘SSNETLIB’..
2003-11-30 17:00:37.27 spid13 Starting up database ‘SPB’.
2003-11-30 17:00:37.27 spid12 Starting up database ‘BD_MTA’.
2003-11-30 17:00:37.27 spid14 Starting up database ‘BD_SPF’.
2003-11-30 17:00:37.27 server Error: 17059, Severity: 18, State: 0
2003-11-30 17:00:37.27 server Operating system error -1073723998: ..
2003-11-30 17:00:37.27 server Unable to load any netlibs.
2003-11-30 17:00:37.27 server SQL Server could not spawn FRunCM thread.
Resolution
The resource-specific registry keys that correspond to the SQL Server cluster resource that you are trying to bring online are missing. This problem also occurs if the values that correspond to the resource-specific registry keys are not correct.

Symptoms
Consider the following two scenarios:
Scenario 1:You install SQL Server 2005 failover cluster on a Windows Server 2008 or Windows Server 2008 R2 failover cluster using the default configuration.On the same system you install a new instance of SQL Server 2008 failover cluster.
Scenario 2: You install two or more instances of SQL Server 2005 failover cluster on a Windows Server 2008 or Windows Server 2008 R2 failover cluster using the default configuration.You upgrade one of them to SQL Server 2008.
In either of these scenarios, you will notice that the SQL Server resource of  all the SQL Server 2005 instances that are currently active on the node where the SQL Server 2008 setup actions are performed, enters a failed state in the Failover Cluster Manager. 
Note: In the above statements, the phrase ‘default configuration’ implies that you install the SQL Server 2005 failover cluster using the default options during the setup process and did not make any changes to the failover action of the SQL Server resource after the setup has been complete. Also any stand alone (non-clustered) instances running on the node are not affected by this problem.
Resolution
The default configuration of SQL Server 2005 failover cluster does not set the following policy on SQL Server resources:
“If resource fails, attempt restart on current node.”
All the instances of SQL server running on a node will always share the highest version of SQL cluster resource dll present on that node. When installing or upgrading to SQL Server 2008 for the first time, the setup process replaces the existing version of SQL cluster resource dll with a newer and a higher version. As part of this procedure, it shuts down SQL Server resources to avoid a system reboot at the end of setup. Hence, if the policy above is not set, the cluster will not attempt to restart the failed SQL Server resources.

Symptoms
When you use Microsoft SQL Server 2008 Configuration Manager, SQL Server 2005 Configuration Manager, SQL Server 2000 Enterprise Manager, or SQL Server 2000 Setup to change SQL Server parameters in a clustered environment, you have to make changes on the active node while the SQL Server cluster resource is online.If SQL Server is not online, you have to bring SQL Server online first.However, in some circumstances, you may be unable to bring SQL Server online.
This article describes how to change SQL Server parameters in a clustered environment when SQL Server is not online or when you cannot bring SQL Server online.
Resolution
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756?(http://support.microsoft.com/kb/322756/) How to back up and restore the registry in WindowsTo change SQL Server parameters in a clustered environment when SQL Server is not online, use one of the following methods.
Method 1Note We recommend that you try to use this method first.Click Start, click Run, type regedit, and then click OK.Locate the quorum disk.To do this, follow these steps:Locate the following registry key:
HKEY_LOCAL_MACHINE\Cluster\QuorumThe Path entry contains the path of the quorum disk. For example, the Path entry contains the following path:
<QuorumDrive>:\MSCSLocate the GUID of the SQL Server cluster resource.To do this, follow these steps:Locate the following registry key:
HKEY_LOCAL_MACHINE\Cluster\ResourcesExamine the Name column of theregistry entries.
Note Several registry entries include “GUID” in the name of the entry. For the default instance, locate the SQL Server cluster resource that includes “SQL Server” in the Name column.
For named instances, locate the SQL Server cluster resources that include “SQL Server (<InstanceName>)” in the Name column.Locate the checkpoint file name.To do this, follow these steps:Locate the following registry key:
HKEY_LOCAL_MACHINE\Cluster\Resources\{GUID}\RegSyncIn the details pane, view the checkpoint registry hives and the corresponding numbers that resemble the following:
For the default instance
00000004SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLSERVER
For a named instance
00000004 SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLSERVERNote For a named instance, X corresponds to the instance ID.
The number is the checkpoint file name.In this example, the checkpoint file name is 00000004.cpt.In Registry Editor, click HKEY_LOCAL_MACHINE.On the File menu, click Load Hive.In the <QuorumDrive>:\<GUID> folder, locate the checkpoint file that you found in step 4.In the Key Name box, type 1, and then click OK.Locate the following registry key to correct the invalid checkpoint registry key value:
HKEY_LOCAL_MACHINE\1\<YourRegistryKey>Note The following examples correctthe MSSQLSERVER checkpoint registry key:Example 1
To correct the invalid path of the Master.mdf file, follow these steps:Locate the following registry key:
HKEY_LOCAL_MACHINE\1\ParametersCorrect the SQLArg0 key.Example 2
To disable the incorrectly enabled VIA protocol, follow these steps:Locate the following registry key:
HKEY_LOCAL_MACHINE\1\SuperSocketNetLib\ViaChange the value of the Enabled entry from 1 to 0.After you correct the registry key,click HKEY_LOCAL_MACHINE\1, click the File menu, and then click Unload Hive.Note After you follow these steps, this checkpoint is fixed and is replicated to the specific node automatically during failover. You can bring theinstance of SQL Server online.
Method 2Note Do not perform SQL cluster group failover between step 1 and step 3.At a command prompt, run one of the following commands to disable the cluster checkpoint for the specific registry subkey: For an instance of SQL Server 2008, run the following command:
cluster . resource “SQL Server (<InstanceName>)” /removecheckpoints:”HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER”Note In this command, MSSQL.x is a placeholder for the instance ID of the instance of SQL Server. You can determine the corresponding value for the system from the value of the MSSQLSERVER registry entry in the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<Instance Names>\SQL\For an instance of SQL Server 2005, run the following command:
cluster res “SQL Server (<InstanceName>)” /removecheck: “Software\Microsoft\Microsoft SQL Server\ MSSQL.x \MSSQLSERVER” For the default instance of SQL Server 2000, run the following commands:
cluster res “SQL Server” /removecheck: “Software\Microsoft\MSSQLServer\MSSQLSERVER”
cluster res “SQL Server” /removecheck: “Software\Microsoft\MSSQLServer\Cluster”Note You have to run the second command only when you add or remove one or more IP addresses on which SQL Server 2000 listens.For a named instance of SQL Server 2000, run the following commands:
cluster res “SQL Server (<InstanceName>)” /removecheck: “SOFTWARE\Microsoft\Microsoft SQL Server\Instance_Name\MSSQLSERVER”
cluster res “SQL Server (<InstanceName>)” /removecheck: “SOFTWARE\Microsoft\Microsoft SQL Server\Instance_Name\Cluster”Note In these commands, Instance_Name is a placeholder for the name of the instance of SQL Server 2000.Additionally, you have to run the second command only when you add or remove one or more IP addresses on which SQL Server 2000 listens.Change the parameter for the clustered instance of SQL Server on all nodes.At a command prompt, run one of the following commands to enable the cluster checkpoint for the specific registry subkey: For an instance of SQL Server 2008, run the following command:
cluster . resource “SQL Server (<InstanceName>)” /addcheckpoints:”HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER”For an instance of SQL Server 2005, run the following command:
cluster res “SQL Server (<InstanceName>)” /addcheck: “Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER” For the default instance of SQL Server 2000, run the following commands:
cluster res “SQL Server” /addcheck: “Software\Microsoft\MSSQLServer\MSSQLSERVER”
cluster res “SQL Server” /addcheck: “Software\Microsoft\MSSQLServer\Cluster”For a named instance of SQL Server 2000, run the following commands:
cluster res “SQL Server (<InstanceName>)” /addcheck: “SOFTWARE\Microsoft\Microsoft SQL Server\Instance_Name\MSSQLSERVER”
cluster res “SQL Server (<InstanceName>)” /addcheck: “SOFTWARE\Microsoft\Microsoft SQL Server\Instance_Name\Cluster”Note The resource name “SQL Server (<InstanceName>)” may be different in your case. To confirm the resource name, start Cluster Administrator, click SQL Group, locate the SQL Server resource properties, and then determine the exact name of the resource.Bring the instance of SQL Server online.

Symptoms
When you install MicrosoftSQL Server 2008 on a Windows Server 2008-based cluster, the cluster validation rule of the setup process may fail. Additionally, you may receive the following error message:

Error : “Microsoft Cluster Service (MSCS) cluster verification errors” failed. The cluster either has not been verified or there are errors or failures in the verification report. Refer to KB953748 or SQL server books online for more information”The setup log filemay contain a message that resembles the following:

2008-05-20 05:27:18 Slp: Evaluating rule: Cluster_VerifyForErrors
2008-05-20 05:27:18 Slp: Rule running on machine: SQLNode_Name
2008-05-20 05:27:18 Slp: Rule evaluation done: Failed
2008-05-20 05:27:18 Slp: Rule evaluation message: The cluster either has not been verified or there are errors or failures in the verification report.For example, the setup log file (Detail.txt) may be located in the following folder:
%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\20090316_112604For a successful validation, the rule will have an entry that resembles the following:
Computer_name: Cluster_VerifyForErrors: Passed
Resolution
The validation process may fail under various conditions. When this issue occurs, you must perform a manual validation to make sure that the hardware configuration is correct before you try any workaround that is mentioned in this article. You can use the references that are mentioned in the “References” section for more information about how to validate clusters in Windows Server 2008-based environments. This helps prevent additional problems that you may experience in the future, if you use the workaround when underlying problems actually exist.