一種可能是數(shù)據(jù)庫文件在增加的時候超時了，而不是平常常以為的具體的SQL語句超時。把 FILEGROWTH 設(shè)置為一個更低的值，可能會恢復(fù)這個錯誤。

FILEGROWTH 的設(shè)置就是在數(shù)據(jù)庫的 Enterprise Manager 中，對數(shù)據(jù)庫的屬性的如下窗口進行設(shè)置：

一旦你的數(shù)據(jù)庫文件大了后，上述超時就可能出現(xiàn)。這時候不要簡單地以為服務(wù)器壓力太大了。也許就是你的一個設(shè)置導(dǎo)致了超時。
默認(rèn)SQL Server 在數(shù)據(jù)庫文件滿了后，是自動增加原數(shù)據(jù)庫文件的10%大小，用來繼續(xù)使用，解決方法就是把上述的文件增長這里設(shè)置為一個更低的百分比或者直接指定增加多少兆字節(jié)。如果是默認(rèn)的10%的話，可能導(dǎo)致的問題在于數(shù)據(jù)庫大小一次性需要增長數(shù)G。
另外：不僅是數(shù)據(jù)文件滿會導(dǎo)致此問題，日志文件滿也一樣。
某一條數(shù)據(jù)更新語句在數(shù)據(jù)庫或日志文件即將滿的時候執(zhí)行，數(shù)據(jù)庫增長的IO操作會導(dǎo)致延時，此延時會阻塞其他數(shù)據(jù)庫操作，連鎖反應(yīng)，形成blocking。
其實此時找出一條正在阻塞的更新語句，在查詢分析器中執(zhí)行，此時是沒有超市時間的。忍過幾分鐘，當(dāng)這條語句執(zhí)行完后，數(shù)據(jù)文件就會增長完成，所有的blocking也就解開了。

 

微軟的 文章招錄:(由機器人翻譯)
替代方法
要變通解決此問題, 請使用下列方法之一：

手動展開數(shù)據(jù)庫。以手動, 展開數(shù)據(jù)庫使用 ALTERDATABASE 語句或 SQLServer 企業(yè)管理器。

增大的應(yīng)用程序，以便有時間來展開數(shù)據(jù)庫服務(wù)器請求 DML 客戶查詢超時值。DML 提示數(shù)據(jù)庫以展開。

例如, 如果使用 SQL 查詢分析器, 默認(rèn)查詢超時值為 0 （無限）。如果正在使用默認(rèn)值, 您不會遇到此問題。如果不使用默認(rèn)值，增大查詢超時值。 可用于其他應(yīng)用程序（無論它們是否基于Web），您在應(yīng)用程序進行更改。 例如, 如果您使用 ADO, 可更改 CommandTimeout 屬性 連接 或 Command 對象。
確定服務(wù)器上數(shù)據(jù)庫擴展多長時間。確定此, SQL 查詢分析器中運行 ALTERDATABASE 語句，然后查看狀態(tài)欄。在您確定此, 設(shè)置客戶超時值為東西大于此值。
不要更改客戶超時值。 繼續(xù)執(zhí)行測試自動擴展并查看多少擴展完成小于客戶超值中。 自動增長 選項設(shè)置為此新（小）值。

該文章在 2012/3/2 23:39:13 編輯過