我爲何很煩在DB服務器上安裝殺毒軟件

      常見的數據庫鏈接問題無外乎是在數據庫服務器本地能夠鏈接SQL Server，但經過其餘服務器就不能夠鏈接。但此次我卻碰到了相反的狀況，在服務器本地沒法經過IP/實例名鏈接，但從其餘服務器卻能夠。並且每次重啓後問題短暫消失，很少久後，又重現。我仍是第一次碰到這樣的問題。經過深究後找到了根本緣由：居然是某殺毒軟件惹的禍。。。。。

                                                                報錯截圖

 

 

  下面分享下個人排錯過程：

      一.本地使用IP/實例名沒法訪問服務器，但經過機器名能夠；

       咱們知道，使用IP/實例名訪問SQL Server時所採用的協議與使用機器名或者"."是不同的，前者是經過SQL Server的TCP/IP方式訪問，後二者是經過命名管道的方式訪問，既然命令管道的方式能夠訪問，說明數據庫用戶沒有被禁用或者沒有被拒絕遠程鏈接，並且問題應該在tcp/ip上，也就是說這應該是一個網絡問題，而不是SQL Server的配置問題。

 

   二.外部機器能夠鏈接進來，也能夠telnet DB服務器IP的1433端口；

       這說明DB服務器的防火牆應該沒有問題，再說，防火牆是防外不防內，內部不能訪問確定跟防火牆沒有關係。

       另外，我在其餘服務器和DB服務器上的cmd中執行netstat -ano|findstr 1433，能夠看到實際上兩臺服務器創建了tcp鏈接；

 

 

    三.在數據庫服務器本地telnet 1433端口，telnet不成功；

分析到這裏的時候，我忽然想起來了以前處理的一個問題，就是服務器本地的使用的tcp端口太多了，達到了上限（65536），致使應用程序新的TCP請求無法分配到TCP端口，所以沒法網絡通信。這個現象跟這個狀況很相似，數據庫服務器本地發起數據庫鏈接時，SSMS要分配一個本地的隨機TCP端口，若是端口不夠用了，確定就不能鏈接SQL Server了，至於外部機器爲何可以鏈接進來，是由於他們使用的是本身的TCP端口來鏈接SQL Server的1433端口，並不須要數據庫服務器單獨再開TCP端口。

根據這個思路，我經過tcpview查看數據庫服務器的端口使用狀況，結果令我失望了，居然很正常，難道是我判斷出錯了，但是按照現象應該就是這樣的呀，無心中看到服務器右下角某數字公司的安全衛士，豁然開朗，安全軟件常常幹影響網絡通信的事情，將其卸載後一切正常。。。。。

 

PS：本文並非黑某殺毒軟件，只是想說市面常見的這些防禦軟件這都是爲我的電腦設計的，服務器的使用狀況跟我的電腦有很大不一樣，請不要輕易在服務器上安裝殺毒軟件，以避免帶來一些意想不到的壞影響。