淺談數據庫連接

　　必須澄清，雖然文章是我總結整理的，但是很多知識的確不是我能研究分析得出來，通過聽培訓、看書、實踐所總結得出，一方面為了給自己備用，以便以后出現問題能解決，另一方面也希望遇到相同問題的朋友能從中得到一些啟示。所以文章里面的知識可能會在很多地方都出現。 　　我們經常會遇到很多連接問題，同時程序員往往也認為連接數據庫只需要簡單地連接→openconnection→操作→close，但是一個簡單的連接動作，背后往往帶有很多東西，充分理解，會對開發及管理有很大的幫助，畢竟連不上服務器其他一切都是白搭： 　　首先，從開發層面，要保證數據庫連接的穩定性： 　　原因一：數據庫連接是很“重”的操作，消耗資源很多 　　在常見的C/S模式中，簡單的連接操作背后潛藏如下操作： 　　1、客戶端與遠程服務器的監聽程序(listenerprogram)建立聯系。 　　2、監聽程序要么創建一個進程或線程來執行數據庫核心程序，要么直接或間接地把客戶請求傳遞給已存在的服務器進程，取決于服務器是否共享服務器。 　　3、為每個session建立新環境，跟蹤它們的行為。建立前還要做賬號密碼匹配。有可能DBMS還要執行登錄觸發器，初始化存儲過程和程序包(如果它們是第一次被調用的話)。 　　4、客戶端進程和服務器進程之間要完成的握手協議。 　　正因為如此，連接池技術才尤為重要。 　　原因二：程序(包括存儲過程)和數據庫之間的交互也要開銷： 　　即使連接建立但未中斷，程序和DBMS之間的上下文切換也有代價。對此，如果DBMS支持數據通過數組傳遞，應該毫不猶豫使用它。 　　一些初級程序員(沒有鄙視的意思)，會很簡單地在每個插入中連接、斷開數據庫，如果有大量數據(過萬已經會出現問題)，就容易耗盡服務器資源。曾經聽過一名微軟工程師說他們去服務客戶的一個例子，一個手機流水線，但是開到第五條線的時候就卡得不行，實在開不了第六條線。后來發現，是編程的時候把循環放在連接的外層，每循環一次，就要連接、斷開一次。造成嚴重的負載。后來把循環放到連接里面，可以開到上百條生產線?？梢娺B接的重要性。 　　然后，從數據庫管理層面： 　　數據庫客戶端應用使用數據庫服務時： 　　第一步、在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，服務器 ，第1行” 　　“用戶‘’ 登錄失敗” 　　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’ 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瀏覽器將設置在低級特權用戶的安全上下文中運行。讓被攻擊的幾率降到最低?？梢詫⑿陆ㄓ脩艏尤隨QLServerXXXSQLBrowser$這個本地組。權限如下： 　　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都支持使用行版本控制的已提交讀事務隔離，但使用它支持快照事務隔離。 　　這個組件默認是不安裝的?？梢栽诎惭b時一起安裝，也可以在安裝文件的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別名： 　　別名是在客戶端配置，不能在服務器設置一次就可以的?？梢允褂肧QL Server Configuration Manager或者SQLServer客戶端網絡實用工具來管理： 　　命名管道連接問題的解決步驟： 　　1、 使用【服務器端網絡實用工具】檢查命名管道配置并確認SQL Server已經監聽了命名管道協議。 　　2、 使用【客戶端網絡實用工具】檢查客戶端的連接協議配置，確保啟用了命名管道?？蛻舳撕头掌鞯哪J管道名稱需要和服務器監聽的一致。 　　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需要維護連接的負擔會非常重?？赡軙猩贁颠B接照顧不過來，容易遇到GNE。如果開啟連接池，負載就能大大降低，問題也就可以解決了。 　　3. 網絡傳輸層問題： 　　由于數據庫經常要傳輸大量的結果集，網絡層比較繁忙。如果兩臺計算機之間的網絡有頻繁重傳現象，或者特定類型的網絡包被某個網絡設備(網關、路由、防火墻等)修改或丟棄，那么GNE出現幾率比較高。這類問題只發生在特定的一組SQLServer服務器和客戶端之間。同一個SQLServer可能有寫客戶端沒有問題，有些有問題?？缇W段或跨子網的客戶端問題比較多。 　　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服務器和客戶端服務器移到物理上比較近、中間網絡設備比較少的網段。修改連接配置，換一種網絡協議。

原文轉自：http://www.anti-gravitydesign.com