Yesterday there was a major outage in the office. Apparently an important application could not connect to it database. The usual means of connecting to a database would be via the following context: server\instance_name. When you connect via this method, the client driver talks to the UDP 1434 port on the DB server to get a connect. Somehow, this did not work today.
There have been some patches done to the servers the night before, but nobody could figure out what was wrong with the instance. None of them would cause such problems. Stranger still, this occurs at the instance level not the SQL server. Another instance on the same SQL server could be connect without any problems.
To complicate the matter, you could connect to this trouble instance via a port connection syntax instead: server,port_num. And worked…
A netmon capture between the client and server show that the client tried to make a connection to the server via UDP 1434 and the server recieves that request… but it does nothing! As if it doesn’t understand what its supposed to do. Netstat veried that the server is still listening on UDP on 1434.
Well, this occur during APAC time and come London start of day, some smart DBA said that they had a similar problem with another DB sometimes back and the resolved the issue!
Apparently, this issue was caused by a missing registry entry:
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\\MSSQLSERVER\SuperSocketNetLib\Np
After recreating this registry from a working instance, it started working immediately!