故障現(xiàn)象：

1、電腦運行緩慢，幾乎不能操縱

2、此數(shù)據(jù)源支持的web程序已down，暴露出來的Error：獲得連接超時。

3、本地連接數(shù)據(jù)庫沒有問題，但是本地的Web程序居然獲得不了數(shù)據(jù)連接

4、CPU利用率、內(nèi)存占用并不高

系統(tǒng)出現(xiàn)當機的可能性很多，造成了確定原因很困難。只能地毯式搜索。

1、系統(tǒng)已經(jīng)進行了全面的查毒、查木馬操作，沒有發(fā)現(xiàn)可疑文件，系統(tǒng)補丁也及時進行修復，被人掛馬的可能性不大。

根據(jù)系統(tǒng)的LOG進行排查：

2、遠程登錄加載的程序錯誤。盡管爆出多次錯誤，但不致于數(shù)據(jù)庫連接中斷。同樣出現(xiàn)類似問題的其它機器并未出現(xiàn)宕機。

3、日志自動增長超時，這個可能性很大。在兩次系統(tǒng)當機前，這個Error曝出的最多，而且系統(tǒng)正常之后，此類ErrorLog消失。

錯誤信息：

原因分析：

默認SQL Server 在數(shù)據(jù)庫文件滿了后，是自動增加原數(shù)據(jù)庫文件的10%大小，用來繼續(xù)使用。還有日志文件，同樣如此。假如你的數(shù)據(jù)庫文件很大了，文件再增加10%，將會是一種較大的負擔。

經(jīng)查詢，其中一數(shù)據(jù)庫的日志文件已經(jīng)有2.37GB之多，如果增加10%，就要增加超過200MB，需要較長的時間時間來完成，這種操作很可能超時。然后其它的插入、更新、查詢操作產(chǎn)生連鎖反應。而且，還有定時器，在不斷進行數(shù)據(jù)訪問，如果出現(xiàn)超時，則很有可能出現(xiàn)死鎖，致使w3wp.exe進程中線程數(shù)明顯增加。

如果數(shù)據(jù)庫在事務中進行更新操作時，而恰巧此時，日志空間不足，需要增加10%的日志空間，而數(shù)據(jù)庫事務執(zhí)行超時時間默認為30秒，這時如果操作超時，事務將進行回滾，此時，其它的數(shù)據(jù)庫操作會產(chǎn)生連鎖反應，形成阻塞。

小型實驗：為了證明這個問題，簡單做了一個小例子，設置：日志滿后自動增加1G的空間。結(jié)果，也出現(xiàn)了此類錯誤，而且在此期間，不能對數(shù)據(jù)庫進行任何操作。

MSDN相關(guān)介紹：

如果您運行的事務需要的日志空間大于可用空間，并且您已經(jīng)為該數(shù)據(jù)庫的事務日志打開自動增長選項，則在完成事務所花費的時間中，有一部分是事務日志按配置量增長所花費的時間。如果該增長量很大，或者有其他因素導致時間延長，則您在其中打開事務的查詢可能因超時錯誤而失敗。數(shù)據(jù)庫的數(shù)據(jù)部分的自動增長可能會造成此類問題。  http://support.microsoft.com/kb/315512/zh-cn

解決方法：將文件增長設置為一個更低的百分比或者直接指定增加多少兆字節(jié)。

事件類型:        信息

事件來源:        MSSQLSERVER

事件種類:        (2)

事件 ID: 5144

日期:                 2009-3-3

事件:                 11:57:18

用戶:                 N/A

描述:

數(shù)據(jù)庫 'databaseName' 中的文件 'databaseName_log' 的自動增長已由用戶取消，或已在 30687 毫秒后超時。請使用 ALTER DATABASE 為此文件設置較小的 FILEGROWTH 值，或顯式設置新的文件大小。

有關(guān)更多信息，請參閱在 http://go.microsoft.com/fwlink/events.asp 的幫助和支持中心。

認真查閱了一些資料，在網(wǎng)絡中也得到幾位同病者的提供的分析結(jié)果，基本已經(jīng)確定了問題的所在。

【編輯推薦】

1. 優(yōu)化SQL Server數(shù)據(jù)庫的經(jīng)驗總結(jié)
2. MySQL***高并發(fā)網(wǎng)站實戰(zhàn)攻略
3. SQL Server查詢速度緩慢解決辦法