• 如何在 SQL 2008 安裝 Performance Dashboard Reports


    http://blog.miniasp.com/post/2011/08/24/Performance-Dashboard-Reports-for-SQL-Server-2008.aspx

    如何在 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 服務之後到現在所累積的效能問題有哪些。

    相關連結

     
  • 相关阅读:
    [转]utf8编码原理详解
    [转]程序员趣味读物:谈谈Unicode编码
    confluence 安装部署
    统计日志10分钟内出现的次数
    Error occurred during initialization of VM Could not reserve enough space for object heap(可能是内核参数的问题)
    Linux服务器性能查看分析调优
    python break ,continue和 pass 语句(八)
    python 循环基础(六)
    python 循环实例(七)
    python 条件控制(五)
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/2913570.html
Copyright © 2020-2023  润新知