首页 > 开发 > 综合 > 正文

连接数据库时发生"一般性网络错误"的另类解释

2024-07-21 02:04:07
字体:
来源:转载
供稿:网友
  连接数据库时发生"一般性网络错误"的另类解释
  
  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
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表