文章标题
引起sql数据库超时的一种问题
错误信息是最常见的那种：microsoft ole db provider for sql server 错误 '80040e31' （[odbc sql server driver]超时已过期）
服务器上看cpu、内存，都非常非常的低呀，这么低的占用率也能导致超时！后来到处查看，后来在事件日志中看到一个非警告的日志：
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超时时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了
服务器上看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%大小，用来继续使用。
如果你的数据库文件很大了，这时候麻烦就来了，因为大文件*10%，是很大的。
然后其它所有的新增操作都会报超时，而这时候其实cpu、内存占用率都非常非常的低。
如果你的数据库文件很大了，这时候麻烦就来了，因为大文件*10%，是很大的。
然后其它所有的新增操作都会报超时，而这时候其实cpu、内存占用率都非常非常的低。
解决方法就是把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。
这个问题，在企业的生产环境中经常遇到。不仅是数据文件满会导致此问题，日志文件满也一样。某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的io操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超时时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了
