数据库超时的其中一种情况
2005年8月23日 10:29今天早上碰到了导致超时的一种不常见的特殊情况。特整理如下：
早上CSDN的论坛回复和发帖都一直报超时,错误信息是最常见的那种：
Microsoft OLE DB Provider for SQL Server 错误 '80040e31'
超时已过期
/Expert/reply.asp，行 110
服务器上看CPU、内存，都非常非常的低呀，这么低的占用率也能导致超时，我晕。后来到处查看，后来在事件日志中看到一个非警告的日志：
事件类型: 信息
事件来源: MSSQLSERVER
事件种类: (2)
事件 ID: 17055
日期: 2005-8-23
事件: 9:39:00
用户: N/A
计算机: ********
描述:
5144:
数据库 '*********' 中文件 '***********' 的自动增长在 453 毫秒后已取消或出现超时。使用 ALTER DATABASE 设置更小的 FILEGROWTH 或设置新的大小。
我倒竟然是数据库文件在增加的时候超时了。而不是平常常以为的具体的SQL语句超时。把 FILEGROWTH 设置为一个更低的值，ok 一切都恢复了。
FILEGROWTH 的设置就是在数据库的 Enterprise Manager 中，对数据库的属性的如下窗口进行设置：
一旦你的数据库文件大了后，上述超时就可能出现。这时候不要简单地以为服务器压力太大了。也许就是你的一个设置导致了超时。
反馈
默认SQL Server 在数据库文件满了后，是自动增加原数据库文件的10%大小，用来继续使用。
如果你的数据库文件很大了，这时候麻烦就来了，CSDN 论坛的这次问题就是在增加这个数据库文件的时候超时了。
然后其它所有的新增操作都会报超时，而这时候其实CPU、内存占用率都非常非常的低。
如果你的数据库文件很大了，这时候麻烦就来了，CSDN 论坛的这次问题就是在增加这个数据库文件的时候超时了。
然后其它所有的新增操作都会报超时，而这时候其实CPU、内存占用率都非常非常的低。
这是一个很土的问题，然而在企业的生产环境中经常遇到。不仅是数据文件满会导致此问题，日志文件满也一样。
某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的IO操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
正如楼上的朋友所问，"dba哪去了？"。文件的监测和日志的truncate，本来就应该是dba常抓不懈的工作。
某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的IO操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
正如楼上的朋友所问，"dba哪去了？"。文件的监测和日志的truncate，本来就应该是dba常抓不懈的工作。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
----------------------------
这句话好像不对，按照KB上的，这个申请文件增长的请求是被操作系统拒绝的，所以不是等几分钟执行完语句就能增长的。解决的方法还是把文件的增长大小设置为一个固定数值而不是百分比。
----------------------------
这句话好像不对，按照KB上的，这个申请文件增长的请求是被操作系统拒绝的，所以不是等几分钟执行完语句就能增长的。解决的方法还是把文件的增长大小设置为一个固定数值而不是百分比。
我在一年多以前就说过这个事情。
另外，用SQL2005就不容易遇到这个问题了哦。
数据库增加10G的大小也不过就是3秒钟。
另外，用SQL2005就不容易遇到这个问题了哦。
数据库增加10G的大小也不过就是3秒钟。