一种可能是数据库文件在增加的时候超时了，而不是平常常以为的具体的SQL语句超时。把 FILEGROWTH 设置为一个更低的值，可能会恢复这个错误。

FILEGROWTH 的设置就是在数据库的 Enterprise Manager 中，对数据库的属性的如下窗口进行设置：

一旦你的数据库文件大了后，上述超时就可能出现。这时候不要简单地以为服务器压力太大了。也许就是你的一个设置导致了超时。
默认SQL Server 在数据库文件满了后，是自动增加原数据库文件的10%大小，用来继续使用，解决方法就是把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。如果是默认的10%的话，可能导致的问题在于数据库大小一次性需要增长数G。
另外：不仅是数据文件满会导致此问题，日志文件满也一样。
某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的IO操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。

 

微软的 文章招录:(由机器人翻译)
替代方法
要变通解决此问题, 请使用下列方法之一：

手动展开数据库。以手动, 展开数据库使用 ALTERDATABASE 语句或 SQLServer 企业管理器。

增大的应用程序，以便有时间来展开数据库服务器请求 DML 客户查询超时值。DML 提示数据库以展开。

例如, 如果使用 SQL 查询分析器, 默认查询超时值为 0 （无限）。如果正在使用默认值, 您不会遇到此问题。如果不使用默认值，增大查询超时值。 可用于其他应用程序（无论它们是否基于Web），您在应用程序进行更改。 例如, 如果您使用 ADO, 可更改 CommandTimeout 属性 连接 或 Command 对象。
确定服务器上数据库扩展多长时间。确定此, SQL 查询分析器中运行 ALTERDATABASE 语句，然后查看状态栏。在您确定此, 设置客户超时值为东西大于此值。
不要更改客户超时值。 继续执行测试自动扩展并查看多少扩展完成小于客户超值中。 自动增长 选项设置为此新（小）值。

该文章在 2012/3/2 23:39:13 编辑过