必須澄清，雖然文章是我總結(jié)整理的，但是很多知識的確不是我能研究分析得出來，通過聽培訓(xùn)、看書、實踐所總結(jié)得出，一方面為了給自己備用，以便以后出現(xiàn)問題能解決，另一方面也希望遇到相同問題的朋友能從中得到一些啟示。所以文章里面的知識可能會在很多地方都出現(xiàn)。

我們經(jīng)常會遇到很多連接問題，同時程序員往往也認(rèn)為連接數(shù)據(jù)庫只需要簡單地連接→openconnection→操作→close，但是一個簡單的連接動作，背后往往帶有很多東西，充分理解，會對開發(fā)及管理有很大的幫助，畢竟連不上服務(wù)器其他一切都是白搭：

首先，從開發(fā)層面，要保證數(shù)據(jù)庫連接的穩(wěn)定性：

原因一：數(shù)據(jù)庫連接是很“重”的操作，消耗資源很多

在常見的C/S模式中，簡單的連接操作背后潛藏如下操作：

1、客戶端與遠(yuǎn)程服務(wù)器的監(jiān)聽程序（listenerprogram)建立聯(lián)系。

2、監(jiān)聽程序要么創(chuàng)建一個進(jìn)程或線程來執(zhí)行數(shù)據(jù)庫核心程序，要么直接或間接地把客戶請求傳遞給已存在的服務(wù)器進(jìn)程，取決于服務(wù)器是否共享服務(wù)器。

3、為每個session建立新環(huán)境，跟蹤它們的行為。建立前還要做賬號密碼匹配。有可能DBMS還要執(zhí)行登錄觸發(fā)器，初始化存儲過程和程序包（如果它們是第一次被調(diào)用的話）。

4、客戶端進(jìn)程和服務(wù)器進(jìn)程之間要完成的握手協(xié)議。

正因為如此，連接池技術(shù)才尤為重要。

原因二：程序（包括存儲過程）和數(shù)據(jù)庫之間的交互也要開銷：

即使連接建立但未中斷，程序和DBMS之間的上下文切換也有代價。對此，如果DBMS支持?jǐn)?shù)據(jù)通過數(shù)組傳遞，應(yīng)該毫不猶豫使用它。

一些初級程序員（沒有鄙視的意思），會很簡單地在每個插入中連接、斷開數(shù)據(jù)庫，如果有大量數(shù)據(jù)（過萬已經(jīng)會出現(xiàn)問題），就容易耗盡服務(wù)器資源。曾經(jīng)聽過一名微軟工程師說他們?nèi)シ?wù)客戶的一個例子，一個手機(jī)流水線，但是開到第五條線的時候就卡得不行，實在開不了第六條線。后來發(fā)現(xiàn)，是編程的時候把循環(huán)放在連接的外層，每循環(huán)一次，就要連接、斷開一次。造成嚴(yán)重的負(fù)載。后來把循環(huán)放到連接里面，可以開到上百條生產(chǎn)線?？梢娺B接的重要性。

然后，從數(shù)據(jù)庫管理層面：

數(shù)據(jù)庫客戶端應(yīng)用使用數(shù)據(jù)庫服務(wù)時：

第一步、在SQL Server上建立一個連接。如果雙方都在一臺機(jī)器上，就是本地連接。如果不在一臺機(jī)器上，就需要通過網(wǎng)絡(luò)層。

第二步、客戶端需要告知SQL Server自己的身份。然后SQLServer需要認(rèn)證（Authentication）是否合法，從而賦予預(yù)設(shè)的授權(quán)（Authorization）

以上的工作有客戶端數(shù)據(jù)驅(qū)動程序（ODBC、OLE DB、NativeClient、JDBC等）和SQL Server交互完成，成功以后客戶端用戶才能開始訪問數(shù)據(jù)。

在連接過程中，如果遇到問題，客戶端驅(qū)動程序一定會拋出錯誤信息。讓我們找到錯誤的原因：

1、  客戶端驅(qū)動沒能找到用戶指定的SQL Server：如

SQL Server doesn’t exist or access denied

雖然說是不存在或者訪問被拒絕，但是其實意味著：指定的SQL Server沒找到

2、  SQL Server已經(jīng)找到，甚至連接已經(jīng)建立，但是因為某種未知原因，連接異常中斷：

[DBMSSOCN] General network error. Chack your networkdocumentation.

或者

A transport level error occurred when sending a request(provider:TCP provider error: 0 an existing connection was forcibly closed bythe remote host)

這種錯誤可能發(fā)生在連接過程中的任何時候，包括建立初期和客戶端指令運(yùn)行時，原因有很多，比較難簡單處理。

3、  用戶認(rèn)證失敗，SQLServer認(rèn)為連接使用了一個非法用戶而拒絕：

Login failed for user “Null”

“消息 18456，級別 14，狀態(tài) 1，服務(wù)器 <computer_name>，第1行”

“用戶‘<user_name>’ 登錄失敗”

4、  認(rèn)證過程中遇到錯誤，認(rèn)證動作異常終止

Failed to generate SSPI context

這種錯誤發(fā)生在一些原有權(quán)力訪問的SQLServer用戶身上。用戶明明有訪問權(quán)力。但是在某些機(jī)器上，某些時段無法連接。

有時候錯誤會間歇發(fā)生甚至?xí)詣酉А?/p>

下面來詳細(xì)說明一下：

一、協(xié)議的選擇與別名：

連接數(shù)據(jù)庫首先要啟用網(wǎng)絡(luò)協(xié)議，無論是本地連接還是網(wǎng)絡(luò)連接。

SQL Server可以同時偵聽多種協(xié)議處理請求?？蛻舳耍ㄟ@里的客戶端是多種的，不是特指前端應(yīng)用程序）會選擇一個協(xié)議連接SQLServer。如果不知道SQLServer正在偵聽哪個協(xié)議，可以配置客戶端按順序嘗試連接：

SQLServer目前常用的有3個：Shared Memory、TCP/IP和Named Pipe

Shared Memory：最簡單的協(xié)議，沒有特殊配置

         由于該協(xié)議僅能連到同一臺計算機(jī)上運(yùn)行的SQLServer。索引對應(yīng)大多數(shù)連接是沒有辦法使用的。但可以在調(diào)試其他協(xié)議的時候進(jìn)行故障界定工作，以確保連接問題是和網(wǎng)絡(luò)層有關(guān)，還是和SQLServer自己有關(guān)系。同時，它也是最快的協(xié)議。

TCP/IP：在Internet上廣泛使用的通用協(xié)議

         包括路由網(wǎng)絡(luò)流量的標(biāo)準(zhǔn)，并提供高級安全功能，是商業(yè)中最常用的協(xié)議。也是SQLServer最常用的網(wǎng)絡(luò)協(xié)議。

Named Pipe：是為局域網(wǎng)開發(fā)的協(xié)議

         內(nèi)存的一部分被某個進(jìn)程用來向另一個進(jìn)程傳遞信息，因此一個進(jìn)程的輸出就是另一個進(jìn)程的輸入。第二個進(jìn)程可以是本地的（與第一進(jìn)程處于同一臺計算機(jī)上），也可以是遠(yuǎn)程的（位于聯(lián)網(wǎng)的計算機(jī)上）。如果你使用過命名管道進(jìn)行編程，會發(fā)現(xiàn)它是利用標(biāo)準(zhǔn)的Win32文件系統(tǒng)API函數(shù)（如ReadFile和WriteFile）來進(jìn)行數(shù)據(jù)的收發(fā)。與系統(tǒng)基層網(wǎng)絡(luò)傳送協(xié)議無關(guān)?；具^程如下：

         （1）、SQLServer服務(wù)器使用CreateNamedPipe函數(shù)創(chuàng)建命名管道并對其進(jìn)行監(jiān)聽。

         （2）、客戶端使用CreateFile和WriteFile函數(shù)試圖連接到服務(wù)器的命名管道。

所以：

1、  命名管道不是一個基層網(wǎng)絡(luò)協(xié)議。即使使用命名管道，也要配置TCP或其他基層網(wǎng)絡(luò)協(xié)議保證客戶端和SQLServer服務(wù)器之間的網(wǎng)絡(luò)連通性。

2、  命名管道是一個要通過系統(tǒng)認(rèn)證的協(xié)議。

因為它首先訪問服務(wù)器的IPC$共享。這一步必須通過Windows認(rèn)證。才能連到SQLServer監(jiān)聽的管道上。這是使用命名管道的最大好處，直接利用Windows內(nèi)置的安全機(jī)制。

應(yīng)該根據(jù)不同要求選擇協(xié)議，如果沒有特殊原因，建議先考慮TCP/IP協(xié)議。

連接決定使用哪種協(xié)議？

首先、由服務(wù)器的網(wǎng)絡(luò)協(xié)議配置控制。如果沒啟用，那么就沒辦法使用。

其次、客戶端也能設(shè)置協(xié)議順序。

最后、客戶端可以設(shè)置某個SQLServer服務(wù)的別名，指定其連接方式，同時客戶端也可對上次成功連接的緩存中使用連接方式。

1.1、       服務(wù)器網(wǎng)絡(luò)配置：

網(wǎng)絡(luò)配置在SQL Server配置管理器（Configuration Manager）的Network Configuration

配置的結(jié)果其實是存放在注冊表：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib下的各個項目里?？梢詮倪@里直接修改（但不建議）。修改需要重啟服務(wù)。

重啟后，檢查SQLServer的errorlog進(jìn)行確認(rèn)。

Shared Memory 正常啟動后信息類似如下：

Xxxx-xx-xx xx:xx:xx.xx Server Server local connectionprovider is ready to accept connection on [\\.\pipe\SQLLocal\MSSQLSERVER].

Named Pipe正常啟動后可以看到：

Xxxx-xx-xx xx:xx:xx.xx Server Server named pipe provider isready to accept connection on [\\.\pipe\sql\query].

TCP/IP正常啟動可以看到：

xxxx-xx-xx xx:xx:xx.xx Server Server is listening on [‘a(chǎn)ny’<ipv4> 1433].—偵聽服務(wù)器上所有IP地址上的1433端口

1.2、       SQL Server Browser的作用：

如果客戶端使用TCP/IP協(xié)議連到SQLServer，就必須指定SQLServer正在偵聽的端口。如果使用NamedPipe，就必須指定管道名字。在2000之前，一臺計算機(jī)只能裝一個實例。所以SQLServer總之偵聽1433端口，當(dāng)2000引入多實例是，只有默認(rèn)實例可以使用這個端口。對于命名實例，每次重啟綁定的端口可能不一樣，而用戶只知道數(shù)據(jù)庫服務(wù)器名字和實例名，為此，SQLServer產(chǎn)品組開發(fā)了一套SQL Server解析協(xié)議（SSRP），用于偵聽UDP1434端口。該偵聽器服務(wù)由一個SQLServer實例兼任。任何一個客戶端要訪問這臺服務(wù)器上的SQL Server實例時，都會先詢問UDP1434端口，然后由SSRP協(xié)議告訴客戶端本臺服務(wù)器上所安裝的SQLServer實例的端口號和管道名字。

但在2003年出現(xiàn)的Slammer病毒導(dǎo)致了這個組件發(fā)出大量的網(wǎng)絡(luò)包，是SQLServer相關(guān)的迄今為止危害最大的病毒。所以從SQLServer2005引入了SQL Server Browser服務(wù)替代原有機(jī)制。

SQL Server Browser使用SSRP偵聽UDP端口，并接受未經(jīng)身份驗證的請求。為了減少惡意攻擊，SQLServer瀏覽器將設(shè)置在低級特權(quán)用戶的安全上下文中運(yùn)行。讓被攻擊的幾率降到最低?？梢詫⑿陆ㄓ脩艏尤隨QLServerXXXSQLBrowser$這個本地組。權(quán)限如下：

l  拒絕通過網(wǎng)絡(luò)訪問該計算機(jī)

l  拒絕本地登錄

l  拒絕以批處理作業(yè)登錄

l  拒絕通過“終端服務(wù)”登錄

l  作為服務(wù)登錄

l  讀寫與網(wǎng)絡(luò)通信（端口和管道）相關(guān)的SQL Server注冊表項。

SQL ServerBrowser啟動后，它會啟動并使用UDP 1434端口。此時會讀取注冊表，識別計算機(jī)上所有SQLServer實例，并注明使用的端口和命名管道。當(dāng)有多個網(wǎng)卡時，會啟用第一個遇到的端口。

         如果SQL Server Browser服務(wù)不運(yùn)行，而你提供了正確的端口號或命名管道，仍然可以連接SQLServer如果默認(rèn)實例在1433端口上運(yùn)行，可以使用TCP/IP連接到默認(rèn)實例。但是以下連接無效：

l  未完全指定所有參數(shù)（例如端口和管道名稱）的情況下，組件嘗試連接到命名實例。

l  生成或傳遞其他組件隨后要用來進(jìn)行重新連接的服務(wù)器/實例信息的組件。

l  未提供端口號或管道就連接到命名實例。

l  在未使用TCP 1433端口的情況下，將DAC連接到命名實例或默認(rèn)實例。

l  枚舉SSMS、企業(yè)管理器或查詢分析器中的服務(wù)器。

如果應(yīng)用程序通過網(wǎng)絡(luò)訪問SQLServer，要停止或禁用SQL Server Browser，必須為每個實例分配一個騰定端口號，然后在應(yīng)用程序代碼中指定該端口號。但還有以下問題：

l  必須更新和維護(hù)客戶端應(yīng)用程序代碼。

l  如果服務(wù)器上的其他服務(wù)或應(yīng)用程序占用了端口，會導(dǎo)致實例不可用。

如果報告：SQL Server doesn’texist or access denied，可以嘗試指定端口，或管道名字，看能否連上，如果連上，是因為UDP 1434在網(wǎng)絡(luò)中禁用了。需要防火墻或網(wǎng)關(guān)打開端口。要注意SQL Server Browser啟動賬號要有讀寫與網(wǎng)絡(luò)通信相關(guān)的SQL Server注冊表項的權(quán)限。如果權(quán)限不夠，不會報錯，也不會返回錯誤信息。

1.3、       客戶端網(wǎng)絡(luò)配置：

應(yīng)用程序都是通過加載SQL Server的數(shù)據(jù)驅(qū)動控件做SQL Server連接。目前有三種：

a.      MDAC（Microsoft數(shù)據(jù)訪問組件）：

包括ODBC和OLE DB借口。主要是非.NET的應(yīng)用服務(wù)。默認(rèn)自帶，但有可能需要更新版本。在命令行中運(yùn)行：cliconfg.exe就可以配置MDAC訪問組件的網(wǎng)絡(luò)協(xié)議。

可以配置協(xié)議及先后順序，還可以餓配置是否使用SSL（網(wǎng)絡(luò)傳輸加密），是否嘗試使用Shared Memory等。同樣可以通過修改注冊表得到效果。

b.      SQL Server Native Client：

是2005以后引入的用于OLE DB和ODBC的獨(dú)立數(shù)據(jù)訪問API。05自帶9.0版本，08自帶10版本。它將SQL Server OLE DB訪問接口和SQL Server ODBC驅(qū)動程序組合成一個本機(jī)的DLL。除原有功能外，還提供新功能。用于創(chuàng)建新應(yīng)用程序或增強(qiáng)現(xiàn)有應(yīng)用程序，使其能在SQLServer2005中引入新功能。如MARS、UDT、查詢通知、快照隔離和XML數(shù)據(jù)類型支持。

如果使用C#等語言，且要使用05、08中新功能那么應(yīng)當(dāng)使用SQL Server的.NET Framework數(shù)據(jù)訪問接口，是VS2005的.NET Framework一部分。為2005、2008提供最強(qiáng)大的數(shù)據(jù)訪問組件。對于新功能，應(yīng)該選擇使用SQL Server Native Client。它和MDAC都支持使用行版本控制的已提交讀事務(wù)隔離，但使用它支持快照事務(wù)隔離。

這個組件默認(rèn)是不安裝的。可以在安裝時一起安裝，也可以在安裝文件的sqlncli.msi中單獨(dú)安裝。如果安裝了，可以在SQL Server Configuration Manager中看到和配置。

c.      Microsoft JDBC Provider：是JAVA專用的。有專門的網(wǎng)絡(luò)配置界面。

1.4、       客戶端網(wǎng)絡(luò)連接選擇機(jī)制：

（1）      SQL Server自己有網(wǎng)絡(luò)協(xié)議配置選項，決定SQL Server偵聽哪些協(xié)議。如果沒開啟，則連接請求不會有反應(yīng)。

（2）      如果有多個實例，每個端口和管道名稱都不一樣。SQLServer Browser通過讀取注冊表信息，能夠知道本服務(wù)器上所有實例的網(wǎng)絡(luò)配置信息。當(dāng)客戶端連接時，會先通過UDP1434向SQL Server Browser通信。這種機(jī)制是網(wǎng)絡(luò)配置可以向客戶端透明。

（3）      客戶端的數(shù)據(jù)庫連接組件上可以配置候選的網(wǎng)絡(luò)協(xié)議，及候選優(yōu)先級。

當(dāng)有多個協(xié)議時，使用順序如下：

1.      在連接字符串（Connection String）中指定

a.      Server關(guān)鍵字：Server=[protocol:]Server[,port]

如指定命名管道：np:Myserver\MyInstance

b.      Network關(guān)鍵字：Network=dbmssocn

兩種方法只能選其一。

2.      客戶端別名：

如果指定了別名，就會去TPC/IP找別名這臺服務(wù)器，不成功就直接報錯，不會嘗試其他網(wǎng)絡(luò)協(xié)議。

3.      尋找相應(yīng)數(shù)據(jù)驅(qū)動程序的”LastConnect”注冊表記錄：

在注冊表中會維護(hù)一組LastConnect記錄，記錄上次連接的網(wǎng)絡(luò)配置。如果1、2步不成功，將會使用這里的配置。如果本次不成功，數(shù)據(jù)驅(qū)動程序會改試方法4

4.      按照數(shù)據(jù)庫驅(qū)動程序的網(wǎng)絡(luò)配置優(yōu)先級選擇網(wǎng)絡(luò)協(xié)議，詢問SQL Server Browser動態(tài)得知端口號或管道名字。當(dāng)所有配置都不成功時，連接才報告失敗。

二、連接失敗檢測步驟——命名管道

Windows中，進(jìn)程間通信機(jī)制有郵槽、管道和套接字等。就管道而言，有命名管道和匿名管道。命名管道通過進(jìn)程間通信（IPC）機(jī)制實現(xiàn)通信。進(jìn)行單向或雙向數(shù)據(jù)通信。

SQL Server命名管道工作原理：

         首先在服務(wù)器上創(chuàng)建一個命名管道并監(jiān)聽，然后客戶端連接這個管道進(jìn)行對話。

1.      命名管道的名稱：

才有UNC格式標(biāo)識命名管道：\\server\Pipe\path_name

\\server部分：指定命名管道所在的服務(wù)器，多用.來代表正在運(yùn)行的本地服務(wù)器。

\pipe: 是一個固定的“硬編碼”字串，表明管道協(xié)議。

\path_name：管道名稱，可以是多級目錄。一般監(jiān)聽的有：\sql\query。

例子：

默認(rèn)實例：\\.\pipe\sql\query

命名實例：\\.\pipe\MSSQL$instancename\sql\query

2.      配置或查看SQL Server監(jiān)聽的命名管道：

使用SQL Server Configuration Manager為每個實例配置格子的網(wǎng)絡(luò)協(xié)議：

3.      驗證SQL Server是否監(jiān)聽了命名管道：

需要檢查errorlog：

                   客戶端的命名管道配置：

                   一般不會特殊配置，默認(rèn)開啟，但建議檢查

1.      客戶端網(wǎng)絡(luò)實用工具——MDAC數(shù)據(jù)庫接口：

Cliconfg.exe，如圖，必須保證SQLServer監(jiān)聽的命名管道名稱和客戶端連接的默認(rèn)管道名稱是一致的。

2.      SQL Server ConfigurationManager——SQL Server Native Client：使用下圖配置

3.      善用客戶端SQL Server別名：

別名是在客戶端配置，不能在服務(wù)器設(shè)置一次就可以的?？梢允褂肧QL Server Configuration Manager或者SQLServer客戶端網(wǎng)絡(luò)實用工具來管理：

命名管道連接問題的解決步驟：

1、  使用【服務(wù)器端網(wǎng)絡(luò)實用工具】檢查命名管道配置并確認(rèn)SQL Server已經(jīng)監(jiān)聽了命名管道協(xié)議。

2、  使用【客戶端網(wǎng)絡(luò)實用工具】檢查客戶端的連接協(xié)議配置，確保啟用了命名管道?？蛻舳撕头?wù)器的默認(rèn)管道名稱需要和服務(wù)器監(jiān)聽的一致。

3、  檢查網(wǎng)絡(luò)連通性。要能ping通服務(wù)器的IP及服務(wù)器名

4、  檢查客戶端是否能夠通過服務(wù)器的Windows認(rèn)證：

Net view \\servername

Net use \\servername\IPC$

如果兩條命令出錯，則表明有訪問SQL Server服務(wù)器權(quán)限上的問題。

5、  確?？蛻舳说卿涃~號有權(quán)限訪問SQL Server。

一些常見的連接問題：

一、多數(shù)是客戶端沒找到命名管道服務(wù)器即SQL Server

[Named Pipes]SQL Server does not exist or access denied.

[Named Pipes]ConnectionOpen(Connect()).

解決方法：

（1）、檢查網(wǎng)絡(luò)連通性，如ping

（2）、檢查SQLServer服務(wù)器端和客戶端的命名管道配置

二、訪問權(quán)限：

Login failed for user ‘NULL’或Login failed foruser anonymous

表明連通沒問題，只是命名管道訪問服務(wù)器權(quán)限上的問題。不要忘記IPC$共享，沒有權(quán)限訪問IPC$就無法使用命名管道?？梢赃\(yùn)行：

net use \\servername\IPC$ 來測試

三、訪問權(quán)限2：

Login failed for user ‘User123’

表明該用戶沒用權(quán)限訪問服務(wù)器的資源或者SQLServer。不是連接問題，而是權(quán)限問題

                   為了避免上面問題：

（1）      建立連接后，如何查看使用的協(xié)議？可以在SSMS中運(yùn)行：

Net_library說明了協(xié)議，如果為LPC，代表使用Shared Memory

（2）      除了使用SSMS之外，另一個就是ODBC數(shù)據(jù)源。運(yùn)行：ODBCAD32.exe。

使用該工具嘗試連接到SQL Server的系統(tǒng)DSN。如果報錯，證明連接有問題。報錯的時候會返回錯誤號，可以使用“net helpmsg 錯誤號”來查詢。

三、連接失敗檢查步驟——TCP/IP

TCP/IP協(xié)議有兩個基本東西：IP地址和端口號。

添加TCP/IP時，需要重啟服務(wù)器。

對于端口號，可以在配置工具中點解TCP/IP，然后選擇屬性，可以看到其偵聽的端口號：

只要端口未被其他進(jìn)程占用，就可以改變這個端口號。一般高于5000的端口號都可以使用。從1024~5000的端口號經(jīng)常會被系統(tǒng)和程序占用，所以不建議取這個范圍?？梢詮倪@個連接查看Windows系統(tǒng)使用的端口號：

http://support.microsoft.com/?id=832017

或者可以使用netstat命令查看偵聽的端口：netstat –an可以看到系統(tǒng)所有使用中的端口號。

客戶端TCP/IP協(xié)議配置：

客戶端默認(rèn)開啟TCP/IP。也可以使用cliconfg.exe來配置。如果默認(rèn)實例不是1433，則需要在Default port做相應(yīng)改變。也可以使用別名指定服務(wù)器的端口。也可以使用動態(tài)端口，如圖：

TCP/IP連接問題的解決步驟：

步驟1：驗證SQLServer是否確實監(jiān)聽了TCP/IP協(xié)議：

                   驗證協(xié)議也需要查看errorlog。如果看到下面一樣，證明已經(jīng)監(jiān)聽了TCP/IP

如果發(fā)現(xiàn)沒有監(jiān)聽，可以使用服務(wù)器網(wǎng)絡(luò)配置工具【svrnetcn.exe】配置。此工具需要下載。

步驟2：驗證服務(wù)器監(jiān)聽的TCP/IP端口和客戶端配置的默認(rèn)值或別名中指定的值一致：

                   除了配置一樣之外，客戶端連接的默認(rèn)端口需要和SQLServer服務(wù)器監(jiān)聽的一致。如果有別名，需要仔細(xì)查看其指定的端口是否正確。

步驟3：檢查網(wǎng)絡(luò)連通性：

                   要確保不僅ping同SQLServer服務(wù)器的IP地址，也要能ping通sqlserver服務(wù)器的名稱。如果名字ping不同，說明DNS或WINS服務(wù)器配置有問題，可以在HOSTS文件（system32\drivers\etc下）中手工加入IP地址和服務(wù)器對，如：

169.254.173.244 MySQLServer

步驟4：使用telnet命令檢查SQLServer監(jiān)聽的端口：

                   要驗證SQLServer監(jiān)聽的端口，可以使用telnet命令，假設(shè)IP為192.168.1.1，端口為1234，可以使用：telnet192.168.1.1 1234。如果成功，那么會顯示一個光標(biāo)在閃的黑色屏幕。如果不成功會返回錯誤信息。

步驟5：檢查登錄用戶的SQLServer訪問權(quán)限：

                   和命名管道一樣，必須確保客戶端登錄賬號有權(quán)限訪問SQL Server。

為了減少配置錯誤，可以使用以下措施：

1、  配置多個靜態(tài)端口：

只需使用服務(wù)器網(wǎng)絡(luò)配置工具在TCP/IP協(xié)議屬性中輸入多個逗號分隔的端口號就可以了。雖然監(jiān)聽多個端口的意義不大，如果認(rèn)為有網(wǎng)絡(luò)性能問題，還不如增加網(wǎng)卡，這樣比提升多端口要好得多。

2、  TCP/IP端口綁定失?。?/p>

如果靜態(tài)端口被占用，會出現(xiàn)以下錯誤信息：

Server SuperSocket Info: Bind failed on TCP port 1433.

對此，可以指定其他端口，或停用一些服務(wù)再重啟SQLServer服務(wù)。如果想查看什么程序占用端口，可以使用PortQry.exe（需下載）獲取。使用說明：

http://support.microsoft.com/default.aspx?kbid=310099

例子：protqry –n Myserver –p TCP –e 1433

3、  檢查連接使用的協(xié)議：

通過SSMS執(zhí)行下面語句即可：

4、  如何訪問防火墻后面的SQLServer：

必須配置防火墻以允許從*ANY*（大于1024的端口）到1433的通信量，及從1433到*ANY*的通信量。

具體說明可以參考技術(shù)文檔：

http://support.microsoft.com/?id=287932

5、  在ManagementStudio中指定連接的協(xié)議和端口：

可以強(qiáng)制使用TCP/IP連接服務(wù)器指定端口。

6、  其他：

在以上步驟都不成功的時候，使用Network Monitor工具捕捉網(wǎng)絡(luò)包來分析。它可以獲取一些其他手段找不到的原因。詳細(xì)參考：

http://support.microsoft.com/default.aspx?kbid=148942

四、一般性網(wǎng)絡(luò)錯誤（GeneralNetwork Error）

1、  可能發(fā)生在連接生命周期的任何一步：

這個問題和“SQL Server doesn’t exists or access denied”有本質(zhì)區(qū)別，后者是連不到SQLServer服務(wù)，但前者是已經(jīng)找到SQLServer服務(wù)，但連接在建立、傳送客戶端查詢指令，或收到SQLServer返回的數(shù)據(jù)結(jié)果集的任何一步發(fā)生了異常中斷。此時要檢查錯誤的詳細(xì)信息：

2、  一般只是偶爾發(fā)生，或者集中在某個時間段發(fā)生，而且很可能會自動消失：

如果時有時無，就需要抓一組Network Monitor的日志，甚至是Windows的內(nèi)核跟蹤，總能定位問題。

3、  問題產(chǎn)生的可能原因非常多：

常見原因：

1.      服務(wù)器的負(fù)荷：

如果服務(wù)器負(fù)荷高，有可能在網(wǎng)絡(luò)中會發(fā)出很多RESET包，在超過重試次數(shù)后，客戶端會中斷連接，拋出GNE。這類問題會影響所有連接，甚至在SQLServer服務(wù)器上的本地連接。

2.      繁忙的應(yīng)用服務(wù)器沒有使用連接池：

在三層應(yīng)用結(jié)構(gòu)中，中間層應(yīng)用服務(wù)器會同時接受大量的數(shù)據(jù)庫登出登入請求，如果沒有使用連接池，SQLServer需要維護(hù)連接的負(fù)擔(dān)會非常重?？赡軙猩贁?shù)連接照顧不過來，容易遇到GNE。如果開啟連接池，負(fù)載就能大大降低，問題也就可以解決了。

3.      網(wǎng)絡(luò)傳輸層問題：

由于數(shù)據(jù)庫經(jīng)常要傳輸大量的結(jié)果集，網(wǎng)絡(luò)層比較繁忙。如果兩臺計算機(jī)之間的網(wǎng)絡(luò)有頻繁重傳現(xiàn)象，或者特定類型的網(wǎng)絡(luò)包被某個網(wǎng)絡(luò)設(shè)備（網(wǎng)關(guān)、路由、防火墻等）修改或丟棄，那么GNE出現(xiàn)幾率比較高。這類問題只發(fā)生在特定的一組SQLServer服務(wù)器和客戶端之間。同一個SQLServer可能有寫客戶端沒有問題，有些有問題?？缇W(wǎng)段或跨子網(wǎng)的客戶端問題比較多。

4.      Windows操作系統(tǒng)層面問題：

SQLServer的連接由Windows建立和維護(hù)，所以Windows層面的許多行為會影響SQLServer的連接穩(wěn)定性。當(dāng)數(shù)據(jù)庫、網(wǎng)絡(luò)很繁忙時，Windows為了維護(hù)自身安全，會有意拒絕一些網(wǎng)絡(luò)請求。造成誤殺。

5.      不恰當(dāng)?shù)南到y(tǒng)設(shè)置：

有時候會從安全性角度考慮，修改一些系統(tǒng)設(shè)置，但是過于嚴(yán)厲的話會導(dǎo)致SQLServer連接的不穩(wěn)定。常見的是TCP設(shè)置，在

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下。

SQLServer層的設(shè)置也有兩個地方可能引起GNE錯誤，都在sp_configure中：

l  Priority boost：SQLServer以高優(yōu)先級啟動。一般情況下不推薦設(shè)置。

l  Lightweight pooling：會使SQLServer切換到纖程模式計劃。會影響SQLServer的運(yùn)行模式，有時會帶來GNE副作用。由于大部分情況下不會帶來明顯的性能提高，所以不建議使用。

6.      防毒軟件和防火墻：

這些軟硬件有可能導(dǎo)致誤殺現(xiàn)象。

7.      網(wǎng)絡(luò)設(shè)備：

有些應(yīng)用會長時間連接數(shù)據(jù)庫，幾乎從來不登出。如果沒有操作請求，連接會長時間處于空閑狀態(tài)。對于這樣的TCP連接，SQLServer會每隔30秒做一次KeepAlive握手。確保連接是否有效。如果客戶端對此沒有反饋，SQLServer會中斷這個連接。當(dāng)客戶端下次使用時，就會收到GNE。有些網(wǎng)絡(luò)設(shè)備會在空閑30~40分鐘后直接斷開連接。也會直接導(dǎo)致GNE。

8.      錯誤的網(wǎng)卡配置：

在集群服務(wù)器上，至少有兩塊網(wǎng)卡。如果心跳線也能訪問公共網(wǎng)絡(luò)，就容易出現(xiàn)GNE。

4、  GNE情況很多，但是還是可以做以下的操作，減緩或者解決：

1．  分析網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，確定網(wǎng)絡(luò)的可靠性

2．  涉及SQLServer服務(wù)器和客戶端服務(wù)器做全面健康檢查，確認(rèn)它的工作正常。

l  Windows日志中不可以有明顯的錯誤

l  CPU不可以長時間100%

l  Windows不可以有系統(tǒng)緩存及內(nèi)存方面的問題。

l  SQL Server的errorlog里不可以有明顯的錯誤，重點錯誤是：AV、內(nèi)存、磁盤、17883/17884

l  SQLServer不可以發(fā)生大范圍、涉及100個以上的連接阻塞問題。

l  檢查sysprocesses系統(tǒng)視圖，不可出現(xiàn)經(jīng)常有大量連接處于runnable/running狀態(tài)。

3．  按照下面方式配置SQLServer服務(wù)器和客戶端服務(wù)器：

（1）、禁用RSS：

找到注冊表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS，將其設(shè)為0.

（2）、禁用TaksOffload：

找到注冊表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOff，將其設(shè)為1

（3）、禁用TCP Chimney：

輸入：netsh in tip set chimney DISABLED

（4）、禁用TCPA：

找到注冊表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA，將其設(shè)為0.

（5）、重啟機(jī)器使設(shè)置生效。

（6）、將所有有關(guān)系的機(jī)器Windows升級到最新的更新版本。網(wǎng)絡(luò)設(shè)備firmware升級到最新。

（7）、檢查SQLServer sp_configure里面priority boost和lightweight pooling是否被改動過。

4．  正確配置網(wǎng)絡(luò)：

（1）、確認(rèn)注冊表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下都是默認(rèn)配置

（2）、再次確認(rèn)沒有配置網(wǎng)卡的Teaming。

（3）、在集群環(huán)境里，確認(rèn)兩塊網(wǎng)卡配置正確。

（4）、確認(rèn)網(wǎng)羅設(shè)備自動關(guān)閉Idle連接的功能已經(jīng)被禁用。

（5）、暫時關(guān)閉防毒軟件和防火墻。

（6）、如果可能，盡量將SQLServer服務(wù)器和客戶端服務(wù)器移到物理上比較近、中間網(wǎng)絡(luò)設(shè)備比較少的網(wǎng)段。修改連接配置，換一種網(wǎng)絡(luò)協(xié)議。