I recently encountered this error on a customer server and wanted to hopefully save many folks the effort to resolve the problem. If you just want the answer skip to the bottom of the page. In my case, I had a two node, two instance SQL Server cluster with a failed instance. When trying to bring the instance online, the service control manager would hang until the timeout period and then litter the event log with the following message:
MSSQLSERVER Error (3) 17052 N/A SQLDEV1 [sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 11; message = [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.
The SQL Server error log indicates that the SQL Server started and was subsequently shut down by the service control manager. If you search for this issue online you'll likely find this knowledge base article: http://support.microsoft.com/kb/307336. It suggests that something might be wrong with the name of your SQL Server cluster resource. In my case, it wasn't the case at all. However, I was not familiar with the environment, I couldn't be sure. To get to the bottom of the issue, more research was necessary.
The issue lies in that a cluster service initiates a connection to SQL Server after the service control manager brings the service online. If it's not able to verify that SQL Server is online, the cluster manager asks the service control manager to stop the service.
So this begs the question, if the SQL Server error log indicates that all is well, why would the cluster think it's not? Answer: it can't connect. Specifically, if the service is a named instance the cluster manager needs to know what port to connect to.
So why didn't it know the port number? Because the SQL Browser service was not running. Simple solution to what looked like a complicated problem.
No comments:
Post a Comment