首先，從開發層面，要保證數據庫連接的穩定性：
原因一：數據庫連接是很“重”的操作，消耗資源很多
在常見的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解析協議（***P），用於偵聽UDP1434端口。該偵聽器服務由一個SQLServer實例兼任。任何一個客戶端要訪問這臺服務器上的 SQL Server實例時，都會先詢問UDP1434端口，然後由***P協議告訴客戶端本臺服務器上所安裝的SQLServer實例的端口號和管道名字。
但在2003年出現的Slammer病毒導致了這個組件發出大量的網絡包，是SQLServer相關的迄今爲止危害最大的病毒。所以從SQLServer2005引入了SQL Server Browser服務替代原有機制。
SQL Server Browser使用***P偵聽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服務器和客戶端服務器移到物理上比較近、中間網絡設備比較少的網段。修改連接配置，換一種網絡協議。