连接数据库时发生

 

"一般性网络错误"

 

的另类解释

 

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