The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

如何在 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 報表

按下開啟舊檔後,報表就會立即出現正確的效能分析報告,如下圖示(點圖可放大顯示)

image

這裡其實包含好幾份子報表,都是相互連動的,所分析出來的資訊之寶貴無法言寓,有心想研究的人建議可參考安裝目錄下的 PerfDash.chm 文件,這裡有每一份報表的詳細說明:

在點選進 (Drill down) 子報表之後,如果要回上一頁,可以按報表左上角的「向後巡覽」按鈕,這樣就可以不用每次重新開啟報表:

在眾多報表之中,我覺得最有用的應該就是 Missing Indexes (遺失的索引):

這份報表可以幫我們找出有哪些表格遺失了某些「可能需要」的索引(切記:越多的索引代表資料寫入速度越慢),然而在分析出所有遺失的索引後,你可以在 Proposed Index 欄位發現他連建立索引的語法都幫你寫好了,可惜的是你無法直接從報表上複製文字下來,只能先匯出 Excel 再複製其 T-SQL 語法:

由於你不應該把所有「可能遺失的索引」都建立起來,因此以下提供一個基本的判斷原則,幫助你選擇到底有哪些索引應該被建立,這調校原則雖然適用於許多情況,但該原則還是僅供參考,設定不好而導致資料庫寫入速度變慢請不要找我負責,因為資料庫的效能調校不僅僅只有這樣的判斷邏輯,還有許多其他的環境因素都有可能影響到調校的策略,像是:硬碟存取速度、應用程式特性、系統資源分配情況、…等等

  • Avg Total User Cost 欄位的數值超過「個位數」以上,就算是蠻高的成本,可以考慮建立索引
  • Avg User Impact 欄位的數值超過 80 以上,也算是蠻高的衝擊,也可以考慮建立該索引

不過再進一步分析 Unique CompilesUser SeeksUser Scans 數量過低的情況,其實建立索引不見得對整體執行效能有幫助(因為該索引的使用率過低),反而會導致寫入效能低落的情況,這時你也可以選擇不建立該索引:

 

§ 最後提醒 §

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

 

相關連結

留言評論