2009-10-07 124 views
1

我的SQL Server 2005存在問題,其中存儲過程特別是運行大容量插入的過程有時需要很長時間才能執行。這個存儲過程,我們稱之爲DatabaseUpdate,需要約2秒才能完成。但是,在20-40%的時間內,花費的時間遠遠超過這個時間,並且很常見的是它會在30秒後超時。間歇SQL Server超時和存儲過程的執行時間差異很大

有什麼奇怪的是,我有一個非常控制的環境。我目前正在查看的日誌顯示了一段時間,其中定期發生完全相同的事件。有少數客戶端,他們都基於定時器發出請求,這些機器都運行原子時鐘同步應用程序。所以我可以幾乎肯定地說,每五分鐘發生一次相同的事件,但是我的存儲過程將一個100Kb文件導入到數據庫中,其執行時間從1.5-30秒改變爲不同。

我以前沒有注意到,因爲我只看到超時錯誤,就是在較長的執行時間正在發生的所有其他更新,所以時間是這樣的:

10:30 2062毫秒 10 :35 24250毫秒 10:40 1921年毫秒 10:45 25703毫秒 10:50 1734毫秒 10:55 25406毫秒 11:00 1625毫秒

任何想法?

回答

1

除了Mitch的建議之外,我還建議通過運行SQL跟蹤來驗證存儲過程的每次調用是否使用相同的「實際」而不是「預計」執行計劃。

另外,驗證每個執行/ BULK INSERT是否正在處理相同或相似數量的記錄,因爲過程插入的記錄越多,執行所需的時間就越長。

您是否認爲您的數據庫可能尺寸不足以支持您的插入?例如,您的數據庫數據文件是否需要增長才能適應其他所有程序的執行?

如果這些元素在每次執行之間是相同的,那麼將會改變的唯一其他元素是數據庫數據本身,因此需要調查統計和索引使用情況。

+0

我有,並且正在運行跟蹤。這些文件的大小始終在20Kb左右,並且我確認了這個持續時間與讀取和寫入的次數無關。 – patrick 2009-10-07 16:30:36

+0

數據庫的大小如何?是否發生自動增長事件以適應批量插入? – 2009-10-07 16:31:51

+0

我看不到發生自動增長事件。您能否澄清一下您將如何驗證:「存儲過程的每次調用都使用相同的」實際「而不是」預計「執行計劃。」我比較了「展示計劃文本(未編碼)」事件,並沒有什麼區別,但你是否指的是其他內容。 – patrick 2009-10-07 19:44:57

1

查看您是否有任何日誌增長或數據庫增長事件。當數據庫大小不正確時,它們會自動增長。在自動增長事件(可能在批量插入期間發生)期間,數據庫將凍結,直到文件生長並初始化爲0。此操作持續很長時間(幾十秒),並且隨着數據庫增長而變得更長,因爲默認的自動增長是從大小開始的百分比,所以自動增長的規模越來越大。

要檢查自動增長事件,請查看ERRORLOG和進入SQL Server:Database/Log Growth性能計數器值。

如果您有數據庫增長事件,則必須將數據庫大小設置爲正確的大小。正確的值取決於您的實際數據負載。您還應該打開NTFS初始化初始化,請參閱Instant Initialization - What, Why and How?。您不能將此設置用於日誌文件。

+0

當自動增長過小時,它會導致超時,因爲它不能夠快速增長,以便進程在超時之前工作。 – HLGEM 2009-10-07 17:12:05

1

難道是[b]鎖定問題? SQL事件探查器顯示的內容(也轉換錯誤和死鎖)?哪些資源(掛)插入等待?

0

調查檢查點。

我在加載大量數據時看到了同樣的事情。

問題是數據庫引擎正在將髒頁從內存寫入磁盤。

使用Perfmon監視磁盤性能,如果出現這種情況,您會在性能下降的同時看到磁盤使用率高峯。