SQL Server Performance Dashboard Reports

SQL Server Performance Dashboard Reports是一組Reporting Services的報表，和SQL Server Management Studio中所介紹的報表一起使用。這些報表允許資料庫管理員快速地確定他們的系統中是否存在瓶頸，瓶頸是否正在發生，捕獲這些附加的診斷資料可能會對解決問題更有協助。例如，系統正在等待disk IO，這是Dashboard就允許使用者可以快速地查看哪一個session，session中的哪一個查詢計劃，查詢計劃中哪一條語句最消耗IO。

Performance dashboard可以協助解決一些普遍的效能問題，包括：

-CPU瓶頸問題（什麼查詢最消耗CPU）
-IO瓶頸問題（什麼查詢最消耗IO）
-由查詢最佳化工具產生的索引推薦方案（未使用索引）
-阻塞問題
-Latch競爭問題

SQLServer2005的效能工具Performance Dashboard是新添加到SQLServer2005的並在SP2發布之後不久就可用的一款擴充工具。具體的安裝參看 [原]安裝SQL Server 2005 Performance Dashboard Reports的技巧。SQL Server 2008/2008 R2/2012的Performance Dashboard報表可以從這裡下載最新的工具包： Microsoft SQL Server 2012 Performance Dashboard Reports。

這些捕獲到報表中的資訊源於SQL Server的動態管理檢視，它不需要額外的跟蹤或資料擷取，資訊一致可用，所以它是一個不怎麼消耗資源的一種管理伺服器的方法。

Reporting Services對於使用Performance Dashboard報表並不是必須要安裝的。

1、下載 SQL Server 2008/2008 R2/2012的Performance Dashboard報表： Microsoft SQL Server 2012 Performance Dashboard Reports ，安裝後在C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Performance Dashboard 下可以找到setup.sql和相關自訂報表。

readme裡頭有安裝的方法，協助檔案裡頭有具體的使用方法。

2、開啟SSMS 執行setup.sql

3、選擇自訂報表performance_dashboard_main.rdl，載入後即可看到效能分析報表：

Performance Dashboard不收集也不儲存任何資訊，而是從SQL Server內部取出當前存在的資料。正因如此，大量的資料都是從某一特定時間開始的，但是有時，你會看到一些曆史資料，作為副產品來查看SQL Server如何工作。曆史資料很有限，但是很有用，我們之後會提到。

我之所以指出這個原因，是因為你必須手動的重新整理Performance Dashboard來擷取你SQL Server最新的活動快照。這也很容易做，只要單擊Performance Dashboard頂端的refresh按鈕就可以了，就像下面這張圖這樣。

現在，我們看看一些Performance Dashboard的主要區域，看看他們能夠告訴我們些什麼。首頁面分五大區塊。

1.查看CPU使用率，如果SQL Server CPU使用率長時間超過80%的話，可能須注意是否I/O造成CPU瓶頸(過度switch)。

System CPU Utilization

對於大多數DBA，System CPU Utilization（系統CPU使用率）圖表非常有用。你能看到至少15分鐘的SQL Server的CPU活動情況，從SQL Server啟動開始，每分鐘一次更新。但是，請注意，如果你剛啟動SQL Server的服務，將沒有CPU的活動圖表，因為還未滿15分鐘，15分鐘後，你會第一次看到這些資料。而在這裡還想強調的是，CPU的使用率並不是一個精確的數值，而是一個大約值，但是一個大約的值也已經足夠了。在下面的例子中，你會看到一個15分鐘CPU資料，並且每次更新之後，這個圖表依舊顯示的是一段15分鐘長的CPU活動的資料。

Performance Dashboard不僅提供了CPU使用狀況的資訊，還提供了許多其他的寶貴資訊，我們來繼續看一看。

2.查看目前請求所等待的類型，這裡可以看出有那些資源競爭的情況(如果等待時間過長)。

SQL Server每秒執行成百上千的操作，但它們並不是同時完成的。也就是說，許多活動通常都需要短期的“等待”。實際上，SQL Server利用數百種不同的等待狀態來解決它們的複雜性。作為一個DBA，我們的目標是將這種等待狀態最小化。等待狀態越多，或者等待時間越長，效能就會越慢。當等待狀態達到正常值的時候，擴充的等待狀態就不在需要，需要將這些狀態鑒別和更正。

SQL Server利用各種DMV來跟蹤這些等待狀態，有趣的是，SQL Server還能收集一些自上次SQL Server服務重啟開始的一些等待狀態的曆史資料，這些曆史資料和當前的等待狀態資訊都是對DBA非常有用的。

在初始的Performance Dashboard螢幕中，你可能會看到下面的表徵圖。注意，只是“可能”看到。這是因為這個圖表顯示的是Performance Dashboard上次重新整理時的當前等待狀態的資訊。很可能當時沒有等待狀態，如果如此，那就不會再螢幕中出現這類圖表。

3.查看目前活動相關資訊，這裡你可以快速看出快取擊中率的數值(建議>90%)。

圖中的User Requests和User Sessions，這些資料都是Performance Dashboard在上次更新時擷取的。另外，elapsed time（消逝時間）和cache hit ratio（緩衝觸發率）的值指的是之前的全部完成的請求的消逝時間總和。點擊藍色的User Requests 或 User Sessions你可以看到下拉的資訊。當點擊User Requests，你可以看到的資訊，顯示出上次更新時的目前使用者請求。（與之前的部分圖一樣，為了省略顯示，這張圖被截斷，真實的表徵圖有更多的資訊。）

當你點擊User Sessions時，你可以看到下列的報表:

這個報表與Management Studio的Current Activity顯示的資訊比較相似，但它能提供更多的資訊。（同樣，這個報表也是被截斷的，真實的報表比這更長。）

4.查看相關曆史資訊，這裡的資料我認為相當有價值，可以看出I/O Read/Writes狀況，以及何種等待類型最多。還有可以找出最耗時的查詢(依CPU、已耗用時間...等)。

雖然Performance Dashboard並不收集曆史資料，但是一些SQL Server的DMV是收集的，我們可以看，這些是利用DMV的資料顯示出的曆史資料：Waits, IO Statistics, 和 Expensive Queries。

Waits

這個報表顯示了一個自SQL Server執行個體重新啟動開始發生的所有等待狀態的一個曆史資料的快照。

在上述的例子中，我們能看到sleep wait state和this SQL Server執行個體記錄的Network IO類別的最大等待狀態。如果想查看更多的詳細資料，可以展開這些狀態類別。這些資訊都非常強大，它可以協助我們去確定這種等待狀態是不是對SQL Server的效能有消極的影響。

IO Statistics

這些曆史報表告訴你哪個資料庫最消耗IO，以及一些其他的附加資訊。下面的是報表的頂端部分，總結的資料庫的IO情況。

是這個報表的另一個部分，能看查看哪一個對象最消耗IO。另外，如果發現了有出現missing index的情況，你可以下拉報表來查看具體是哪個missing index，這樣就可以把它重新加上。

Expensive Queries

這部分提供了我們在其他查詢報表所看到的相似的資訊，但它顯示的是SQL Server中當前被加入緩衝的那些查詢語句。這樣我們就能給我們更好的展示，來看我們的伺服器究竟發生了什麼。有六種不同方式的結果排序選項（每一種都將形成一個單獨的報表）。你也可以下拉查看詳細資料。

5.綜合資訊可以快速探索如資料庫總覽、擴充事件..等。

Active Traces

Active Traces鑒別了當前SQL Server執行個體中所執行的所有trace。即使你不能運行Profiler Trace，你依然可以看到這個active trace資訊。為什麼呢？這是因為SQL Server一直在自動地為你跟蹤這些事件，當你在這個實力上執行一個Profiler Trace是，你會看到如下的資訊。

Databases

Databases的報表提供了一個當前執行個體中資料庫的快速探索，可以快速查看這些主要資料庫的配置選項。

Missing Indexes

最後一個報表列出了SQL Server所確定的所有missing index。這個分析沒有Database Engine Tuning Advisor所做的那麼全面，但它顯示出了明顯的missing index。其實我們只是希望在這個列表中不出現任何的missing index，這代表我們的資料庫設計的更好。

最後提醒一下各位：

這些統計資訊的資料來源大多來自於 SQL Server 裡所謂的 動態管理檢視 ( DMV )，這些資訊是從資料庫實體 (Instance) 啟動之後所累積的動態資訊，所以 SQL Server 跑得越久，所收集到的資訊越精準，也越能找出在啟動 SQL Server 服務之後到現在所累積的效能問題有哪些。

相關文章：

如何在 SQL 2008 安裝 Performance Dashboard Reports

[SQL]SQL Server 2008使用Extended Events SSMS Addin + Performance Dashboard Reports來監看系統

善用Performance Dashboard Reports