When it comes to managing a SQL Server failover cluster, it’s not uncommon to encounter resource-related issues. One common problem is when the SQL Server resource fails to come online in the failover cluster manager. In this article, we will explore a solution to this issue and discuss the steps to fix it.

The first step in troubleshooting this problem is to check if the ERRORLOG is being generated. The ERRORLOG file contains valuable information about the errors encountered by SQL Server. To find the location of the ERRORLOG file, you can refer to the article “SQL SERVER – Where is ERRORLOG? Various Ways to Find ERRORLOG Location”. Once you have located the ERRORLOG file, review its content for any relevant error messages.

One possible error message that you may encounter is:

2016-10-27 08:27:09.71 spid10s Error: 26054, Severity: 16, State: 1.
2016-10-27 08:27:09.71 spid10s Could not find any IP address that this SQL Server instance depends upon. Make sure that the cluster service is running, that the dependency relationship between SQL Server and Network Name resources is correct, and that the IP addresses on which this SQL Server instance depends are available. Error code: 0x103.

This error indicates that the SQL Server instance is unable to find the IP address it depends on. To resolve this issue, ensure that the cluster service is running, the dependency relationship between SQL Server and Network Name resources is correct, and the IP addresses are available.

Another error message that may be present in the ERRORLOG is:

2016-10-27 06:28:11.72 spid10s Error: 17182, Severity: 16, State: 1.
2016-10-27 06:28:11.72 spid10s TDSSNIClient initialization failed with error 0x103, status code 0xa. Reason: Unable to initialize the TCP/IP listener. No more data is available.

This error indicates a failure in initializing the TCP/IP listener. To resolve this issue, check for any previous errors and review the errors immediately preceding this one in the error log.

There may be other error messages in the ERRORLOG that provide additional information about the cause of the resource failure. It is important to carefully review the entire log to identify any related problems.

In one particular case, the customer reported that they had changed the virtual server name of the SQL Server. This change resulted in the resources being recreated without proper dependencies. To fix this issue, it was necessary to correct the dependencies in the cluster manager.

The dependency tree for the SQL Server resource is as follows:

SQL Server > Depends on All Disks and Network Name.
Network Name > Depends on IP Address.
IP Address > Depends on None.
Disks > Depends on None.

If there are mount points, they would have a dependency on the disk. Additionally, the SQL Server Agent depends on the SQL Server resource.

To view the dependencies in the Cluster Manager, you can use the built-in tools. Once the dependencies were corrected, the SQL Server resource was able to come online successfully.

If you have encountered a similar error with a different solution, we would love to hear about it. Please share your experience in the comments below.