|
今天早上碰到了导致超时的一种不常见的特殊情况。特整理如下： Microsoft OLE DB Provider for SQL Server 错误 ‘80040e31’ 事件类型: 信息 我倒竟然是数据库文件在增加的时候超时了。而不是平常常以为的具体的SQL语句超时。把 FILEGROWTH 设置为一个更低的值，ok 一切都恢复了。 FILEGROWTH 的设置就是在数据库的 Enterprise Manager 中，对数据库的属性的如下窗口进行设置： 一旦你的数据库文件大了后，上述超时就可能出现。这时候不要简单地以为服务器压力太大了。也许就是你的一个设置导致了超时。 反馈# re: 数据库超时的其中一种情况2005-8-23 10:35 by ghj1976 默认SQL Server 在数据库文件满了后，是自动增加原数据库文件的10%大小，用来继续使用。
如果你的数据库文件很大了，这时候麻烦就来了，CSDN 论坛的这次问题就是在增加这个数据库文件的时候超时了。 然后其它所有的新增操作都会报超时，而这时候其实CPU、内存占用率都非常非常的低。 # re: 数据库超时的其中一种情况2005-8-23 10:36 by ghj1976 解决方法就是把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。
# re: 数据库超时的其中一种情况2005-8-23 10:38 by rIPPER dba哪去了？ :)
# re: 数据库超时的其中一种情况2005-8-23 12:30 by ocean 没错，微软有专门一篇文章说这个问题：
http://support.microsoft.com/?id=305635 # re: 数据库超时的其中一种情况2005-8-23 13:36 by Jacob 这是一个很土的问题，然而在企业的生产环境中经常遇到。不仅是数据文件满会导致此问题，日志文件满也一样。
某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的IO操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。 其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。 正如楼上的朋友所问，"dba哪去了？"。文件的监测和日志的truncate，本来就应该是dba常抓不懈的工作。 # re: 数据库超时的其中一种情况2005-8-23 23:39 by ocean 其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
—————————- # re: 数据库超时的其中一种情况2005-8-23 23:54 by Benny Ng 我还是不明白..那我要做的措施是什么?(针对这个情况)
# re: 数据库超时的其中一种情况2005-8-24 15:53 by 怡红公子 我在一年多以前就说过这个事情。
另外，用SQL2005就不容易遇到这个问题了哦。 数据库增加10G的大小也不过就是3秒钟。 # 哈哈！你被贴了。2005-8-24 17:40 by 透明 http://gigix.blogdriver.com/gigix/936726.html
# re: 数据库超时的其中一种情况2005-8-25 1:43 by 流言社 哎，到处都是“你小子被贴了”
# re: 数据库超时的其中一种情况2006-3-8 10:45 by zjbmax 遇到数据库中很多进程被阻塞或死锁的情况怎么解决？（就是在sql2000的企业管理器的“管理”中的“当前活动”“锁/进程ID”中发现的）
|