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

我們經常會遇到很多連線問題，同時程式設計師往往也認為連線資料庫只需要簡單地連線→openconnection→操作→close，但是一個簡單的連線動作，背後往往帶有很多東西，充分理解，會對開發及管理有很大的幫助，畢竟連不上伺服器其他一切都是白搭：

首先，從開發層面，要保證資料庫連線的穩定性：

原因一：資料庫連線是很“重”的操作，消耗資源很多

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

1、客戶端與遠端伺服器的監聽程式（listenerprogram)建立聯絡。

2、監聽程式要麼建立一個程式或執行緒來執行資料庫核心程式，要麼直接或間接地把客戶請求傳遞給已存在的伺服器程式，取決於伺服器是否共享伺服器。

3、為每個session建立新環境，跟蹤它們的行為。建立前還要做賬號密碼匹配。有可能DBMS還要執行登入觸發器，初始化儲存過程和程式包（如果它們是第一次被呼叫的話）。

4、客戶端程式和伺服器程式之間要完成的握手協議。

正因為如此，連線池技術才尤為重要。

原因二：程式（包括儲存過程）和資料庫之間的互動也要開銷：

即使連線建立但未中斷，程式和DBMS之間的上下文切換也有代價。對此，如果DBMS支援資料通過陣列傳遞，應該毫不猶豫使用它。

一些初級程式設計師（沒有鄙視的意思），會很簡單地在每個插入中連線、斷開資料庫，如果有大量資料（過萬已經會出現問題），就容易耗盡伺服器資源。曾經聽過一名微軟工程師說他們去服務客戶的一個例子，一個手機流水線，但是開到第五條線的時候就卡得不行，實在開不了第六條線。後來發現，是程式設計的時候把迴圈放在連線的外層，每迴圈一次，就要連線、斷開一次。造成嚴重的負載。後來把迴圈放到連線裡面，可以開到上百條生產線。可見連線的重要性。

然後，從資料庫管理層面：

資料庫客戶端應用使用資料庫服務時：

第一步、在SQL Server上建立一個連線。如果雙方都在一臺機器上，就是本地連線。如果不在一臺機器上，就需要通過網路層。

第二步、客戶端需要告知SQL Server自己的身份。然後SQLServer需要認證（Authentication）是否合法，從而賦予預設的授權（Authorization）

以上的工作有客戶端資料驅動程式（ODBC、OLE DB、NativeClient、JDBC等）和SQL Server互動完成，成功以後客戶端使用者才能開始訪問資料。

在連線過程中，如果遇到問題，客戶端驅動程式一定會丟擲錯誤資訊。讓我們找到錯誤的原因：

1、  客戶端驅動沒能找到使用者指定的SQL Server：如

SQL Server doesn’t exist or access denied

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

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

[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)

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

3、  使用者認證失敗，SQLServer認為連線使用了一個非法使用者而拒絕：

Login failed for user “Null”

“訊息 18456，級別 14，狀態 1，伺服器 <computer_name>，第1行”

“使用者‘<user_name>’ 登入失敗”

4、  認證過程中遇到錯誤，認證動作異常終止

Failed to generate SSPI context

這種錯誤發生在一些原有權力訪問的SQLServer使用者身上。使用者明明有訪問權力。但是在某些機器上，某些時段無法連線。

有時候錯誤會間歇發生甚至會自動消失。

下面來詳細說明一下：

一、協議的選擇與別名：

連線資料庫首先要啟用網路協議，無論是本地連線還是網路連線。

SQL Server可以同時偵聽多種協議處理請求。客戶端（這裡的客戶端是多種的，不是特指前端應用程式）會選擇一個協議連線SQLServer。如果不知道SQLServer正在偵聽哪個協議，可以配置客戶端按順序嘗試連線：

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

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

         由於該協議僅能連到同一臺計算機上執行的SQLServer。索引對應大多數連線是沒有辦法使用的。但可以在除錯其他協議的時候進行故障界定工作，以確保連線問題是和網路層有關，還是和SQLServer自己有關係。同時，它也是最快的協議。

TCP/IP：在Internet上廣泛使用的通用協議

         包括路由網路流量的標準，並提供高階安全功能，是商業中最常用的協議。也是SQLServer最常用的網路協議。

Named Pipe：是為區域網開發的協議

         記憶體的一部分被某個程式用來向另一個程式傳遞資訊，因此一個程式的輸出就是另一個程式的輸入。第二個程式可以是本地的（與第一程式處於同一臺計算機上），也可以是遠端的（位於聯網的計算機上）。如果你使用過命名管道進行程式設計，會發現它是利用標準的Win32檔案系統API函式（如ReadFile和WriteFile）來進行資料的收發。與系統基層網路傳送協議無關。基本過程如下：

         （1）、SQLServer伺服器使用CreateNamedPipe函式建立命名管道並對其進行監聽。

         （2）、客戶端使用CreateFile和WriteFile函式試圖連線到伺服器的命名管道。

所以：

1、  命名管道不是一個基層網路協議。即使使用命名管道，也要配置TCP或其他基層網路協議保證客戶端和SQLServer伺服器之間的網路連通性。

2、  命名管道是一個要通過系統認證的協議。

因為它首先訪問伺服器的IPC$共享。這一步必須通過Windows認證。才能連到SQLServer監聽的管道上。這是使用命名管道的最大好處，直接利用Windows內建的安全機制。

應該根據不同要求選擇協議，如果沒有特殊原因，建議先考慮TCP/IP協議。

連線決定使用哪種協議？

首先、由伺服器的網路協議配置控制。如果沒啟用，那麼就沒辦法使用。

其次、客戶端也能設定協議順序。

最後、客戶端可以設定某個SQLServer服務的別名，指定其連線方式，同時客戶端也可對上次成功連線的快取中使用連線方式。

1.1、       伺服器網路配置：

網路配置在SQL Server配置管理器（Configuration Manager）的Network Configuration

配置的結果其實是存放在登錄檔：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib下的各個專案裡。可以從這裡直接修改（但不建議）。修改需要重啟服務。

重啟後，檢查SQLServer的errorlog進行確認。

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 [‘any’<ipv4> 1433].—偵聽伺服器上所有IP地址上的1433埠

1.2、       SQL Server Browser的作用：

如果客戶端使用TCP/IP協議連到SQLServer，就必須指定SQLServer正在偵聽的埠。如果使用NamedPipe，就必須指定管道名字。在2000之前，一臺計算機只能裝一個例項。所以SQLServer總之偵聽1433埠，當2000引入多例項是，只有預設例項可以使用這個埠。對於命名例項，每次重啟繫結的埠可能不一樣，而使用者只知道資料庫伺服器名字和例項名，為此，SQLServer產品組開發了一套SQL Server解析協議（SSRP），用於偵聽UDP1434埠。該偵聽器服務由一個SQLServer例項兼任。任何一個客戶端要訪問這臺伺服器上的SQL Server例項時，都會先詢問UDP1434埠，然後由SSRP協議告訴客戶端本臺伺服器上所安裝的SQLServer例項的埠號和管道名字。

但在2003年出現的Slammer病毒導致了這個元件發出大量的網路包，是SQLServer相關的迄今為止危害最大的病毒。所以從SQLServer2005引入了SQL Server Browser服務替代原有機制。

SQL Server Browser使用SSRP偵聽UDP埠，並接受未經身份驗證的請求。為了減少惡意攻擊，SQLServer瀏覽器將設定在低階特權使用者的安全上下文中執行。讓被攻擊的機率降到最低。可以將新建使用者加入SQLServerXXXSQLBrowser$這個本地組。許可權如下：

l  拒絕通過網路訪問該計算機

l  拒絕本地登入

l  拒絕以批處理作業登入

l  拒絕通過“終端服務”登入

l  作為服務登入

l  讀寫與網路通訊（埠和管道）相關的SQL Server登錄檔項。

SQL ServerBrowser啟動後，它會啟動並使用UDP 1434埠。此時會讀取登錄檔，識別計算機上所有SQLServer例項，並註明使用的埠和命名管道。當有多個網路卡時，會啟用第一個遇到的埠。

         如果SQL Server Browser服務不執行，而你提供了正確的埠號或命名管道，仍然可以連線SQLServer如果預設例項在1433埠上執行，可以使用TCP/IP連線到預設例項。但是以下連線無效：

l  未完全指定所有引數（例如埠和管道名稱）的情況下，元件嘗試連線到命名例項。

l  生成或傳遞其他元件隨後要用來進行重新連線的伺服器/例項資訊的元件。

l  未提供埠號或管道就連線到命名例項。

l  在未使用TCP 1433埠的情況下，將DAC連線到命名例項或預設例項。

l  列舉SSMS、企業管理器或查詢分析器中的伺服器。

如果應用程式通過網路訪問SQLServer，要停止或禁用SQL Server Browser，必須為每個例項分配一個騰定埠號，然後在應用程式程式碼中指定該埠號。但還有以下問題：

l  必須更新和維護客戶端應用程式程式碼。

l  如果伺服器上的其他服務或應用程式佔用了埠，會導致例項不可用。

如果報告：SQL Server doesn’texist or access denied，可以嘗試指定埠，或管道名字，看能否連上，如果連上，是因為UDP 1434在網路中禁用了。需要防火牆或閘道器開啟埠。要注意SQL Server Browser啟動賬號要有讀寫與網路通訊相關的SQL Server登錄檔項的許可權。如果許可權不夠，不會報錯，也不會返回錯誤資訊。

1.3、       客戶端網路配置：

應用程式都是通過載入SQL Server的資料驅動控制元件做SQL Server連線。目前有三種：

a.      MDAC（Microsoft資料訪問元件）：

包括ODBC和OLE DB藉口。主要是非.NET的應用服務。預設自帶，但有可能需要更新版本。在命令列中執行：cliconfg.exe就可以配置MDAC訪問元件的網路協議。

可以配置協議及先後順序，還可以餓配置是否使用SSL（網路傳輸加密），是否嘗試使用Shared Memory等。同樣可以通過修改登錄檔得到效果。

b.      SQL Server Native Client：

是2005以後引入的用於OLE DB和ODBC的獨立資料訪問API。05自帶9.0版本，08自帶10版本。它將SQL Server OLE DB訪問介面和SQL Server ODBC驅動程式組合成一個本機的DLL。除原有功能外，還提供新功能。用於建立新應用程式或增強現有應用程式，使其能在SQLServer2005中引入新功能。如MARS、UDT、查詢通知、快照隔離和XML資料型別支援。

如果使用C#等語言，且要使用05、08中新功能那麼應當使用SQL Server的.NET Framework資料訪問介面，是VS2005的.NET Framework一部分。為2005、2008提供最強大的資料訪問元件。對於新功能，應該選擇使用SQL Server Native Client。它和MDAC都支援使用行版本控制的已提交讀事務隔離，但使用它支援快照事務隔離。

這個元件預設是不安裝的。可以在安裝時一起安裝，也可以在安裝檔案的sqlncli.msi中單獨安裝。如果安裝了，可以在SQL Server Configuration Manager中看到和配置。

c.      Microsoft JDBC Provider：是JAVA專用的。有專門的網路配置介面。

1.4、       客戶端網路連線選擇機制：

（1）      SQL Server自己有網路協議配置選項，決定SQL Server偵聽哪些協議。如果沒開啟，則連線請求不會有反應。

（2）      如果有多個例項，每個埠和管道名稱都不一樣。SQLServer Browser通過讀取登錄檔資訊，能夠知道本伺服器上所有例項的網路配置資訊。當客戶端連線時，會先通過UDP1434向SQL Server Browser通訊。這種機制是網路配置可以向客戶端透明。

（3）      客戶端的資料庫連線元件上可以配置候選的網路協議，及候選優先順序。

當有多個協議時，使用順序如下：

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

a.      Server關鍵字：Server=[protocol:]Server[,port]

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

b.      Network關鍵字：Network=dbmssocn

兩種方法只能選其一。

2.      客戶端別名：

如果指定了別名，就會去TPC/IP找別名這臺伺服器，不成功就直接報錯，不會嘗試其他網路協議。

3.      尋找相應資料驅動程式的”LastConnect”登錄檔記錄：

在登錄檔中會維護一組LastConnect記錄，記錄上次連線的網路配置。如果1、2步不成功，將會使用這裡的配置。如果本次不成功，資料驅動程式會改試方法4

4.      按照資料庫驅動程式的網路配置優先順序選擇網路協議，詢問SQL Server Browser動態得知埠號或管道名字。當所有配置都不成功時，連線才報告失敗。

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

Windows中，程式間通訊機制有郵槽、管道和套接字等。就管道而言，有命名管道和匿名管道。命名管道通過程式間通訊（IPC）機制實現通訊。進行單向或雙向資料通訊。

SQL Server命名管道工作原理：

         首先在伺服器上建立一個命名管道並監聽，然後客戶端連線這個管道進行對話。

1.      命名管道的名稱：

才有UNC格式標識命名管道：\\server\Pipe\path_name

\\server部分：指定命名管道所在的伺服器，多用.來代表正在執行的本地伺服器。

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

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

例子：

預設例項：\\.\pipe\sql\query

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

2.      配置或檢視SQL Server監聽的命名管道：

使用SQL Server Configuration Manager為每個例項配置格子的網路協議：

 

3.      驗證SQL Server是否監聽了命名管道：

需要檢查errorlog：

                   客戶端的命名管道配置：

                   一般不會特殊配置，預設開啟，但建議檢查

1.      客戶端網路實用工具——MDAC資料庫介面：

Cliconfg.exe，如圖，必須保證SQLServer監聽的命名管道名稱和客戶端連線的預設管道名稱是一致的。

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

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

別名是在客戶端配置，不能在伺服器設定一次就可以的。可以使用SQL Server Configuration Manager或者SQLServer客戶端網路實用工具來管理：

 

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

1、  使用【伺服器端網路實用工具】檢查命名管道配置並確認SQL Server已經監聽了命名管道協議。

2、  使用【客戶端網路實用工具】檢查客戶端的連線協議配置，確保啟用了命名管道。客戶端和伺服器的預設管道名稱需要和伺服器監聽的一致。

3、  檢查網路連通性。要能ping通伺服器的IP及伺服器名

4、  檢查客戶端是否能夠通過伺服器的Windows認證：

Net view \\servername

Net use \\servername\IPC$

如果兩條命令出錯，則表明有訪問SQL Server伺服器許可權上的問題。

5、  確保客戶端登入賬號有許可權訪問SQL Server。

一些常見的連線問題：

一、多數是客戶端沒找到命名管道伺服器即SQL Server

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

[Named Pipes]ConnectionOpen(Connect()).

解決方法：

（1）、檢查網路連通性，如ping

（2）、檢查SQLServer伺服器端和客戶端的命名管道配置

二、訪問許可權：

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

表明連通沒問題，只是命名管道訪問伺服器許可權上的問題。不要忘記IPC$共享，沒有許可權訪問IPC$就無法使用命名管道。可以執行：

net use \\servername\IPC$ 來測試

三、訪問許可權2：

Login failed for user ‘User123’

表明該使用者沒用許可權訪問伺服器的資源或者SQLServer。不是連線問題，而是許可權問題

                   為了避免上面問題：

（1）      建立連線後，如何檢視使用的協議？可以在SSMS中執行：

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

（2）      除了使用SSMS之外，另一個就是ODBC資料來源。執行：ODBCAD32.exe。

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

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

TCP/IP協議有兩個基本東西：IP地址和埠號。

新增TCP/IP時，需要重啟伺服器。

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

只要埠未被其他程式佔用，就可以改變這個埠號。一般高於5000的埠號都可以使用。從1024~5000的埠號經常會被系統和程式佔用，所以不建議取這個範圍。可以從這個連線檢視Windows系統使用的埠號：

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

或者可以使用netstat命令檢視偵聽的埠：netstat –an可以看到系統所有使用中的埠號。

客戶端TCP/IP協議配置：

客戶端預設開啟TCP/IP。也可以使用cliconfg.exe來配置。如果預設例項不是1433，則需要在Default port做相應改變。也可以使用別名指定伺服器的埠。也可以使用動態埠，如圖：

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

步驟1：驗證SQLServer是否確實監聽了TCP/IP協議：

                   驗證協議也需要檢視errorlog。如果看到下面一樣，證明已經監聽了TCP/IP

如果發現沒有監聽，可以使用伺服器網路配置工具【svrnetcn.exe】配置。此工具需要下載。

步驟2：驗證伺服器監聽的TCP/IP埠和客戶端配置的預設值或別名中指定的值一致：

                   除了配置一樣之外，客戶端連線的預設埠需要和SQLServer伺服器監聽的一致。如果有別名，需要仔細檢視其指定的埠是否正確。

步驟3：檢查網路連通性：

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

169.254.173.244 MySQLServer

步驟4：使用telnet命令檢查SQLServer監聽的埠：

                   要驗證SQLServer監聽的埠，可以使用telnet命令，假設IP為192.168.1.1，埠為1234，可以使用：telnet192.168.1.1 1234。如果成功，那麼會顯示一個游標在閃的黑色螢幕。如果不成功會返回錯誤資訊。

步驟5：檢查登入使用者的SQLServer訪問許可權：

                   和命名管道一樣，必須確保客戶端登入賬號有許可權訪問SQL Server。

 

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

1、  配置多個靜態埠：

只需使用伺服器網路配置工具在TCP/IP協議屬性中輸入多個逗號分隔的埠號就可以了。雖然監聽多個埠的意義不大，如果認為有網路效能問題，還不如增加網路卡，這樣比提升多埠要好得多。

2、  TCP/IP埠繫結失敗：

如果靜態埠被佔用，會出現以下錯誤資訊：

Server SuperSocket Info: Bind failed on TCP port 1433.

對此，可以指定其他埠，或停用一些服務再重啟SQLServer服務。如果想檢視什麼程式佔用埠，可以使用PortQry.exe（需下載）獲取。使用說明：

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

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

3、  檢查連線使用的協議：

通過SSMS執行下面語句即可：

4、  如何訪問防火牆後面的SQLServer：

必須配置防火牆以允許從*ANY*（大於1024的埠）到1433的通訊量，及從1433到*ANY*的通訊量。

具體說明可以參考技術文件：

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

5、  在ManagementStudio中指定連線的協議和埠：

可以強制使用TCP/IP連線伺服器指定埠。

6、  其他：

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

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

 

四、一般性網路錯誤（GeneralNetwork Error）

1、  可能發生在連線生命週期的任何一步：

這個問題和“SQL Server doesn’t exists or access denied”有本質區別，後者是連不到SQLServer服務，但前者是已經找到SQLServer服務，但連線在建立、傳送客戶端查詢指令，或收到SQLServer返回的資料結果集的任何一步發生了異常中斷。此時要檢查錯誤的詳細資訊：

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

如果時有時無，就需要抓一組Network Monitor的日誌，甚至是Windows的核心跟蹤，總能定位問題。

3、  問題產生的可能原因非常多：

常見原因：

1.      伺服器的負荷：

如果伺服器負荷高，有可能在網路中會發出很多RESET包，在超過重試次數後，客戶端會中斷連線，丟擲GNE。這類問題會影響所有連線，甚至在SQLServer伺服器上的本地連線。

2.      繁忙的應用伺服器沒有使用連線池：

在三層應用結構中，中間層應用伺服器會同時接受大量的資料庫登出登入請求，如果沒有使用連線池，SQLServer需要維護連線的負擔會非常重。可能會有少數連線照顧不過來，容易遇到GNE。如果開啟連線池，負載就能大大降低，問題也就可以解決了。

3.      網路傳輸層問題：

由於資料庫經常要傳輸大量的結果集，網路層比較繁忙。如果兩臺計算機之間的網路有頻繁重傳現象，或者特定型別的網路包被某個網路裝置（閘道器、路由、防火牆等）修改或丟棄，那麼GNE出現機率比較高。這類問題只發生在特定的一組SQLServer伺服器和客戶端之間。同一個SQLServer可能有寫客戶端沒有問題，有些有問題。跨網段或跨子網的客戶端問題比較多。

4.      Windows作業系統層面問題：

SQLServer的連線由Windows建立和維護，所以Windows層面的許多行為會影響SQLServer的連線穩定性。當資料庫、網路很繁忙時，Windows為了維護自身安全，會有意拒絕一些網路請求。造成誤殺。

5.      不恰當的系統設定：

有時候會從安全性角度考慮，修改一些系統設定，但是過於嚴厲的話會導致SQLServer連線的不穩定。常見的是TCP設定，在

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

SQLServer層的設定也有兩個地方可能引起GNE錯誤，都在sp_configure中：

l  Priority boost：SQLServer以高優先順序啟動。一般情況下不推薦設定。

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

6.      防毒軟體和防火牆：

這些軟硬體有可能導致誤殺現象。

7.      網路裝置：

有些應用會長時間連線資料庫，幾乎從來不登出。如果沒有操作請求，連線會長時間處於空閒狀態。對於這樣的TCP連線，SQLServer會每隔30秒做一次KeepAlive握手。確保連線是否有效。如果客戶端對此沒有反饋，SQLServer會中斷這個連線。當客戶端下次使用時，就會收到GNE。有些網路裝置會在空閒30~40分鐘後直接斷開連線。也會直接導致GNE。

8.      錯誤的網路卡配置：

在叢集伺服器上，至少有兩塊網路卡。如果心跳線也能訪問公共網路，就容易出現GNE。

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

1．  分析網路拓撲結構，確定網路的可靠性

2．  涉及SQLServer伺服器和客戶端伺服器做全面健康檢查，確認它的工作正常。

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

l  CPU不可以長時間100%

l  Windows不可以有系統快取及記憶體方面的問題。

l  SQL Server的errorlog裡不可以有明顯的錯誤，重點錯誤是：AV、記憶體、磁碟、17883/17884

l  SQLServer不可以發生大範圍、涉及100個以上的連線阻塞問題。

l  檢查sysprocesses系統檢視，不可出現經常有大量連線處於runnable/running狀態。

3．  按照下面方式配置SQLServer伺服器和客戶端伺服器：

（1）、禁用RSS：

找到登錄檔：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS，將其設為0.

（2）、禁用TaksOffload：

找到登錄檔：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOff，將其設為1

（3）、禁用TCP Chimney：

輸入：netsh in tip set chimney DISABLED

（4）、禁用TCPA：

找到登錄檔：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA，將其設為0.

（5）、重啟機器使設定生效。

（6）、將所有有關係的機器Windows升級到最新的更新版本。網路裝置firmware升級到最新。

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

4．  正確配置網路：

（1）、確認登錄檔：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下都是預設配置

（2）、再次確認沒有配置網路卡的Teaming。

（3）、在叢集環境裡，確認兩塊網路卡配置正確。

（4）、確認網羅裝置自動關閉Idle連線的功能已經被禁用。

（5）、暫時關閉防毒軟體和防火牆。

（6）、如果可能，儘量將SQLServer伺服器和客戶端伺服器移到物理上比較近、中間網路裝置比較少的網段。修改連線配置，換一種網路協議。