?

連接數據庫時發生

?

"一般性網絡錯誤"

?

的另類解釋

?

Revision History:

Version	Date	Creator	Description
1.0.0.1	2003-11-15	鄭昀	草稿

Implementation Scope ：

本文檔將說明 出現一種不容易想到原因的訪問數據庫時發生“一般性網絡錯誤”，錯誤報告的來源是 ADODB ，錯誤號是“ - 2147467259 ，或者 0x80004005 ” 。

?

繼續閱讀之前，我們假設您熟悉以下知識：

n ???????? Microsoft SQL Server 2000

n ???????? Microsoft ADO

關鍵詞：

SQL Server 、 ADO 、 DBMSSOCN 、 0x80004005

?

現象

一天，突然有這么一個問題擺在面前：

用戶瀏覽工作流系統時 , 突然跑出來這么一個錯誤：

Microsoft VBScript 編譯器錯誤 錯誤 '800a03f6' ? 缺少 'End' ? /iisHelp/common/500-100.asp ， 行 242 ? Microsoft OLE DB Provider for SQL Server 錯誤 '80004005' ? [DBMSSOCN] 一般性網絡錯誤。請檢查網絡文檔。 ? /xxx/yyyframe.asp ， 行 23

?

經過排查，確定真正的原因在于調用 ADO 連接 SQL Server 2000 時，發生異常，錯誤描述就是“ [DBMSSOCN] 一般性網絡錯誤。請檢查網絡文檔。 ”，至于那個“ Microsoft OLE DB Provider for SQL Server 錯誤 '80004005' ”其實并沒有太多意義。

?

為什么會突然出現“ [DBMSSOCN] 一般性網絡錯誤。 ”呢？

服務器頁面調用的是封 裝好的 COM+ STA 組件，連接 SQL Server 2000 的其實是這個組件。

后來又提供一個比較重要的信息，當這些事情發生的時候，注意到 COM+ 應用的進程占用了 200MB 的內存。

初步的猜想

以前曾經在其他地方遇到過這種錯誤。

但是，那是因為網卡或者網線閃斷 (“network is down”) ，造成連接數據庫失敗，服務又不停地試著去連接。不知道在什么情況下，服務不斷報告：

錯誤環境說明 : 運行 SQL 命令從數據庫讀取記錄時發生 COM 異常 ; 錯誤說明 :[dbmssocn] 一般性網絡錯誤。請檢查網絡文檔。 錯誤號 :-2147467259

“ [ dbmssocn] ”指的是，當前用 TCP/IP 協議與數據庫通信。

?

但是，這次環境的網絡質量沒有問題。

模擬試驗

專家指出可能是因為同一臺服務器和 SQL Server 之間的連接都沒有 Close,所以導致連接達到被允許的最大數目，從而被全部關閉 。

于是我們試驗，看看一臺服務器被允許與 SQL Server 建立最多多少個連接。

更多信息

測試程序中重用了原工程中 InitADOCmd (_Command** ppiCmd) 方法。

這個方法利用 ADO.Command::put_ActiveConnection 方法來建立數據庫連接的：

varConn = _bstr_t("Provider=SQLOLEDB.1;……”); hr = t_piCmd->put_ActiveConnection(varConn);

?

在 Windows XP 環境中，循環調用這個函數到了 1980 次，程序就出現幾秒鐘的停頓。之后，就得到 0x80004005 的錯誤返回值。這個值是由 put_ActiveConnection 方法返回的，并不是異常。所以看不到 ADO 異常描述。

我們通過測試程序停滯時，立刻用一個 VBS 腳本再次請求建立數據庫連接。于是， VBS 腳本一起停滯，隔了幾秒鐘后，拋出異常，錯誤描述為：

"[DBNETLIB][ConnectionOpen (PreLoginHandshake()).] 一般性網絡錯誤。請檢查網絡文檔。 "

?

之后的 1981 、 1982 、 ... 次 put_ActiveConnectio 調用，都會是同一個錯誤返回值。

?

在 SQL Server 事件探查器中，看到 1980 次調用之前，都只有 Audit Login 事件。除非關閉測試程序，才會唰地一下所有的 Audit Logout 事件出來了。

?

有時候，當第 1981 次建立連接的請求被 SQL Server 2000 認為超出允許范圍時， SQL Server 2000 會 主動 將這一千多個的連接同時全部中斷。于是乎，在 SQL Server 事件探查器中，你也可以看到唰地一下所有的 Audit Logout 事件出來了。

?

如果測試程序維持著這些數據庫連接的話，內存會持續增長，如下所示：

?

在 WinXP 上 (Win2000 上允許連接的數目少 ) ， ? 情況 1 ： 單純反復執行 ADO.Command::put_ActiveConnection ，則只有 “Audit Login” 事件，沒有 Logout 事件。這種請求最多達到 1980 之后，就會出現 “ 一般性網絡錯誤 ” 。 ? 情況 2 ： 如果是反復執行 ADO.Command::put_ActiveConnection 方法，然后又執行了查詢 ，返回記錄集，則這種循環最多達到 483 之后，就會出現 “ 一般性網絡錯誤 ” 。 ? 在實際測試中，第 1 種情況，最開始 Demo 用了 6MB 內存，最后累積的內存是： 104MB 。 ? 第 2 種情況下，最開始 Demo 用了 6MB 內存，最后累積的內存是： 39.5MB 。

?

?

?

?

?

?

?

你可以通過下面的 SQL 語句察看當前與 SQL Server 保持的連接都來自于哪里，有多少個：

SELECT dbid,DB_NAME(dbid) as DBName,hostname,status,last_batch FROM sysprocesses WHERE ? DB_NAME(dbid)='%YourDatabaseName%' AND (last_batch > 'YY-MM-DD MM:SS:00') ORDER BY last_batch DESC

?

總結：

雖然這種情況出現的比較罕見，但是如果排除了網絡質量原因，你也許可以注意一下當前服務器與 SQL Server 的 connection 數目是否維持在一個正在高漲的數量 。

當連接不斷增加的時候，就要當心，服務器連接數據庫是有一定限制的，而且達到最大值后，其他程序再次請求連接時，就可能得到“一般性網絡錯誤”的警告，而且錯誤號80004005也并沒有說明到底發生了什么，SQL Server和ADO并不會告訴你連接數已經達到最大值。

?

Disclaimers ：

本文檔所包含的信息代表了在發布之日， zhengyun 對所討論問題的當前看法。本文檔不應理解為 zhengyun 一方的承諾， zhengyun 不保證所給信息在發布之日以后的準確性。

本文檔僅供參考。

用戶必須遵守所有適用的版權法。在不對版權法所規定的權利加以限制的情況下，如未得到 zhengyun 和 CSDN.Net 明確的書面許可，不得出于任何目的、以任何形式或手段（電子的、機械的、影印、錄制等等）復制、傳播本文的任何部分，也不得將其存儲或引入到檢索系統中。

?

thank tian&wu

Writen by zhengyun_ustc(at)hotmail.com

?

?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=12736