有沒有可能在短短幾秒內回答這個問題？也許你試圖查看性能監視器PerfMon里面的性能計數器。里面有大約1000個名稱各異的不同計數器。你可能會問：“Skipped Ghosted Records/sec”（每秒跳過的幻影記錄數）= 10，這個數值好還是壞？正確的回答是，這個數值可能并不重要。不過，有些計數器確實很重要。本文將幫助你找出這類計數器，還會教你如何為最常見的性能問題排除故障。

想開始入手，先從下列網址安裝SQL Heartbeat工具：
http://www.sqlsolutions.com/downloads/activity-monitor/Download.html
連接到你的服務器后，你會看到服務器樹結構中的兩個類別：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文鏈接：http://www.sqlsolutions.com/articles/articles/Become_SQL_performance_Expert_in_few_simple_steps.htm