統計信息更新似乎會導致問題

Question

今天早上醒來，我們的羣集關閉了一個頁面。它馬上回來了。我發現有關IO的條目花費超過15秒的日誌錯誤日誌。我們的監控服務器試圖ping服務器併發生超時錯誤。

我檢查了我們的一個監測工具，看看早上4點半發生了什麼。似乎是在我們的一個大型數據庫上更新統計數據。該工具顯示我們的磁盤正在被最大化。我看到其中一個磁盤的繁忙時間非常繁忙。

現在sqlagent正在按照字母順序進行其他所有數據庫的操作。我們確實有自動更新統計信息 - 但我認爲這是根據需要發生的。我現在沒有啓用任何統計更新作業（我知道 - 作業監視器沒有顯示任何正在運行的作業），所以我不確定是什麼造成了這種情況。

http://support.microsoft.com/default.aspx?scid=kb;en-us;195565 - 證實了我對自動恆壓器的必要性質的看法。

昨晚6:30左右也發生過同樣的事情 - 在同一個大型數據庫上 - 從...語句中選擇一些statsman。

磁盤是在SAN上，我們正在運行的是最新版本的SQL 2005

Answer 1

如果您收到15秒IO錯誤，我將在一個較低的水平開始診斷，檢查是否有驅動程序有關到io最近已經更新，例如Powerpath emulex等。當我在遇到錯誤的io子系統之前遇到這個錯誤，並且不是直接SQL時，那是使磁盤承載並顯示問題的組件。

Answer 2

15秒的錯誤並不總是正確的，有時是由CPU時間漂移引起的，請參見Event ID 833: I/O requests taking longer than 15 seconds。驗證I/O請求是否確實需要這麼長時間（請注意，操作系統性能計數器受到相同時間漂移問題的影響）。

過時的統計數據是每個人都最喜歡的，也是第一個責備任何性能問題，但事實上它們很少是根本原因。通過調查問題查詢的執行計劃，可以查看錯誤的統計信息，它們顯示爲估計的行數與範圍和掃描運算符上的實際行數之間的顯着差異。

如果您認爲您必須每晚都進行一次完整的更新統計（我懷疑），那麼必須計劃您的I/O子系統支持所需的容量，如果數據庫很大，則使用全面掃描的更新統計信息必須一次讀取整個數據庫，因此相應規劃，包括從SAN到SQL的I/O帶寬。