點擊“Online Activity/SQL Heartbeat”節(jié)點，你會立即看到五個不同的圖表。但是最好點擊“Historical Data”（歷史數(shù)據(jù)），等待一兩天，等到累積了更準確的衡量指標為止。之后，你該查看圖表上的哪些內(nèi)容呢？首先，你應該關(guān)注一下Waits圖表：

順便說一下，你有沒有注意到這張圖上的周期性模式？比如說，周末期間活動比較少，到了晚上活動增加。為了更全面地了解數(shù)據(jù)庫在正常工作時間段的運行狀況，你在分析時可以將這些時段排除在外（特別是由于這些時段可能是進行完全備份的時候）。我們可以排除這類數(shù)據(jù)，讓我們的圖表更流暢：

下一步是查看哪個類別最糟糕。如果主色是藍色或黃色（代表讀取或?qū)懭耄?，那么你的服務器是磁盤輸入/輸出密集型的。下面是個示例：

為什么是輸入/輸出密集型的？點擊Physical R/W圖表。問題可能出在工作負載上，比如說輸入/輸出操作次數(shù)太多： 

非常頻繁的輸入/輸出活動可能是糟糕的高速緩存命中率引起的。你可以點擊Cache Hits（高速緩存命中）按鈕來證實：

注意：不要使用性能監(jiān)視器PerfMon所報告的“Cache Hits Ratio”（高速緩存命中率）。PerfMon報告的只是“醫(yī)院里的平均溫度”而已——它是對周末和繁忙時段、夜間索引碎片整理和白天操作求平均值，用的是不同的使用模式。

有時候，“高速緩存命中率”足夠好，但是延遲很差。點擊Seek Time（尋道時間）按鈕來證實：

50毫秒（ms）意味著，服務器每秒只能執(zhí)行20次輸入/輸出操作。這樣的速度僅僅相當于老式軟盤！
有些服務器是處理器密集型的，下面是一臺典型的處理器密集型服務器的模樣：

一般來說，如果服務器是處理器密集型的，情況并不壞，只要絕對數(shù)值不是很高（千萬要牢記：Y軸表示服務器每秒使用所有處理器時的處理器毫秒，所以在4個處理器上，每秒使用處理器最多可以有4000毫秒。）但是如果處理使用率的絕對值很高，那么點擊Query Stats（查詢統(tǒng)計數(shù)字）按鈕。你會看到按處理器、讀取和寫入分類的前十大有問題的查詢。這些查詢很可能是需要優(yōu)化的對象。

順便說一下，你每天可以通過電子郵件來獲得所有這些報告。只要在SQL Heartbeat中進行配置：點擊工具欄中的Reports（報告）按鈕。

現(xiàn)在，其實只剩下了一個次要的方面。你有沒有看到上面的紅色尖峰？這些是鎖。各種各樣的鎖都很危險。每天一小時的處理器使用時間沒什么問題，但是1分鐘的鎖定時間會導致超時、客戶不高興。死鎖更為嚴重。

為了給鎖和死鎖排除故障，請從下列網(wǎng)址安裝SQL Deadlock Detector：
http://www.sqlsolutions.com/downloads/sql-deadlock-detector/Download.html
連接到同一臺服務器，在數(shù)據(jù)收集了幾小時后查看事件列表。

有時候，鎖包括幾十個進程。從SQL Deadlock Detector里面，你能獲得關(guān)于參與鎖的進程的所有細節(jié)：

提供的信息包括鎖定表的名稱、具體的T-SQL語句以及父存儲過程。

小結(jié)
你可以迅速確定自己的SQL服務器其運行狀況是否良好。實際上，說到處理最常見的性能問題，你只要遵照上述步驟，就能夠成為SQL服務器性能方面的專家。

zhaohang