如何在 SQL 2008 安裝 Performance Dashboard Reports
微軟在 SQL Server 2005 Service Pack 2 推出的時候也釋出了一套免費的 Performance Dashboard Reports 自訂報表，透過此報表可以很輕易的分析出整台 SQL Server 的執行效能，是一個非常非常實用的效能分析工具，幾乎是每位 DBA 必備的工具之一，可惜的是到了 SQL Server 2008 之後就不再更新，以致於無法正常安裝到 SQL Server 2008 之後的版本，本文章將說明正確的安裝步驟，讓此報表也能夠在 SQL Server 2008 上正確執行。
在我們下載完 SQL Server 2005 Performance Dashboard Reports 之後，直接點擊 *.msi 檔進行安裝，安裝到選取安裝路徑時，請記得要選取正確的 SQL Server 2008 的安裝目錄才行，如下圖示請點選 Browse 按鈕：
然後預設的安裝路徑為 C:\Program Files (x86)\Microsoft SQL Server\90\Tools\PerformanceDashboard\ 我們只要把該路徑的 90 修改成 100 即是 SQL Server 2008 的預設安裝路徑，不過其實安裝在哪裡都沒什麼關係，因為之後報表還是需要被手動載入，但基本上我不會亂裝到其他的路徑：
安裝完後在安裝目錄下會看見一個 setup.sql 指令檔，這個指令檔必須手動到 SQL Server 執行，才會在 msdb 資料庫建立起 Performance Dashboard Reports 所需的函數與預存程序：
若在 SQL Server 2005 資料庫伺服器執行這個指令檔 ( Service Pack 2 以後的更新 ) 並不會有任何問題，但是在 SQL Server 2008 的資料庫伺服器就會遇到以下錯誤：
Msg 207, Level 16, State 1, Procedure usp_Main_GetCPUHistory, Line 6
無效的資料行名稱 'cpu_ticks_in_ms'。
Msg 15151, Level 16, State 1, Line 1
無法 尋找 物件 'usp_Main_GetCPUHistory'，因為它不存在或您沒有權限。
這個錯誤的主因出在於原本在 SQL Server 2005 裡有個 DMV (Dynamic Management Views) 叫做 sys.dm_os_sys_info，在這個版本的 DMV 有個 cpu_ticks_in_ms 欄位，但在 SQL Server 2008 之後的版本該欄位被修改成 ms_ticks，所以你必須手動修改 setup.sql 指令檔，在 第 218 行的地方將該欄位修正，修正後重新執行一次就可以建立完成。
接著就是利用 Management Studio 從伺服器層級開啟自訂報表，如下圖示：
然後切換至 Performance Dashboard Reports 的安裝目錄並選取 performance_dashboard_main.rdl 報表
按下開啟舊檔後，報表就會立即出現正確的效能分析報告，如下圖示（點圖可放大顯示）
這裡其實包含好幾份子報表，都是相互連動的，所分析出來的資訊之寶貴無法言寓，有心想研究的人建議可參考安裝目錄下的 PerfDash.chm 文件，這裡有每一份報表的詳細說明：
在點選進 (Drill down) 子報表之後，如果要回上一頁，可以按報表左上角的「向後巡覽」按鈕，這樣就可以不用每次重新開啟報表：
在眾多報表之中，我覺得最有用的應該就是 Missing Indexes (遺失的索引)：
這份報表可以幫我們找出有哪些表格遺失了某些「可能需要」的索引（切記：越多的索引代表資料寫入速度越慢），然而在分析出所有遺失的索引後，你可以在 Proposed Index 欄位發現他連建立索引的語法都幫你寫好了，可惜的是你無法直接從報表上複製文字下來，只能先匯出 Excel 再複製其 T-SQL 語法：
由 於你不應該把所有「可能遺失的索引」都建立起來，因此以下提供一個基本的判斷原則，幫助你選擇到底有哪些索引應該被建立，這調校原則雖然適用於許多情況， 但該原則還是僅供參考，設定不好而導致資料庫寫入速度變慢請不要找我負責，因為資料庫的效能調校不僅僅只有這樣的判斷邏輯，還有許多其他的環境因素都有可 能影響到調校的策略，像是：硬碟存取速度、應用程式特性、系統資源分配情況、…等等
- 當 Avg Total User Cost 欄位的數值超過「個位數」以上，就算是蠻高的成本，可以考慮建立索引
- 當 Avg User Impact 欄位的數值超過 80 以上，也算是蠻高的衝擊，也可以考慮建立該索引
不過再進一步分析 Unique Compiles、User Seeks、User Scans 數量過低的情況，其實建立索引不見得對整體執行效能有幫助（因為該索引的使用率過低），反而會導致寫入效能低落的情況，這時你也可以選擇不建立該索引：
§ 最後提醒 §
這些統計資訊的資料來源大多來自於 SQL Server 裡所謂的 動態管理檢視 ( DMV )，這些資訊是從資料庫實體 (Instance) 啟動之後所累積的動態資訊，所以 SQL Server 跑得越久，所收集到的資訊越精準，也越能找出在啟動 SQL Server 服務之後到現在所累積的效能問題有哪些。
