The common database connectivity problem is that SQL Server can be connected locally on the database server, but it cannot be connected through other servers. But this time I ran into the opposite situation, the server cannot be connected locally through the ip/instance name, but it can be from another server. And the problem disappears after each reboot, and it's not long before it reappears. This is the first time I have ever encountered such a problem. Through the drill down to find the root cause: unexpectedly is an anti-virus software caused by the curse .....
Error
Share my troubleshooting process below:
I. Local use of the ip/instance name can not access the server, but through the machine name;
We know that the protocol used to access SQL Server using the ip/instance name is the same as using the machine name or "." is not the same, the former is accessed through SQL Server TCP/IP, the latter is accessed through a named pipe, since the command pipeline can be accessed, indicating that the database user is not disabled or is not denied remote connection, and the problem should be on TCP/IP, In other words, this should be a network problem, not a configuration problem with SQL Server.
Two. The external machine can be connected or telnet to the 1433 port of the DB server IP;
This indicates that the DB server firewall should be no problem, besides, the firewall is anti-external, internal inaccessible must not be related to the firewall.
In addition, I execute netstat-ano|findstr 1433 in cmd on the other server and DB server, and I can see that the two servers actually establish TCP connection;
Three. Telnet is unsuccessful on the database server local Telnet 1433 port;
Analysis here, I suddenly think of a problem before processing, is that the server local use of the TCP port too much, reached the upper limit (65536), resulting in the application of new TCP requests can not be allocated to the TCP port, and therefore cannot network traffic. This phenomenon is similar to this situation, when the database server initiates a database connection locally, SSMs allocates a local random TCP port, if the port is not enough, it must not be able to connect to the SQL Server, as to why the external machine can connect in, Because they are using their own TCP port to connect to SQL Server 1433 ports, there is no need for the database server to open the TCP port separately.
According to this idea, I through the TCPView view database server port usage, the results let me disappointed, unexpectedly very normal, is I judge error, but according to the phenomenon should be so ah, inadvertently see the server in the lower right corner of a digital company's security guard, enlightened, Security software often dries things that affect network communication, unloading everything after it is normal .....
PS: This article is not a black anti-virus software, just want to say that the market common these protection software is designed for personal computers, the use of servers and personal computers are very different, please do not easily install anti-virus software on the server, so as not to bring some unexpected bad impact.
Why would I bother installing antivirus software on a DB server