找出系統效能問題的第一步—資料庫的效能

AgilePoint 的系統架構是IIS 上的一個Application, 因此通常其效能問題的發生的原因通常與一般網頁的應用程式相同, 因此在追查系統效能上, 最常發生的問題是發生在資料庫存取的問題上.
通常資料庫的效能問題, 常出現的問題在於SQL 的執行計劃(Execution Plan), 目前不論Oracle 或SQL Server 都是採用Cost-Base , 也就是依照資料的筆數與分佈的情形計算各種執行計劃的cost, 來決定用那一鍵值或那一種方式讀取效率最高.
因此在處理資料庫效能問題上, 通常程序如下:
1. 以SQL Profiler 找出使用IO量最大的SQL:

2. 先點選檔案新增追蹤

3. 無特殊目的可採用預設的選項, 並設定存放的目錄檔案名稱

4. 點選執行後系統會開始搜集系統的效能數據,
可特別注意兩個欄位CPU 與Reads, CPU 表示執行這段SQL 所耗費的時間, Reads 表示讀取冊數, 如果Reads 的次數很高, 通常需要分析這段SQL 是否有問題.

進一步的分析, 一個簡單的方法是將這段SQL 拿到SQL Server Management Studio ,
可將此SQL 開啟一個新的執行視窗, 貼上SQL 後, 可點選顯示估計執行計劃, 則SQL 下方會顯示其評估的結果.

可將執行計劃儲存為檔案交由資料庫的專家分析.

或可點選執行計劃之單一節點, 觀察其採用的執行計畫, 特別注意其估計的資料列數目與認知中應有的實際數是否有極大差異, 我們曾遇過設定正確, 可是統計確是錯誤的狀況, 原因不明,因此即使設定正確, 亦要根據執行計劃的估計比數判斷是否有問題.

若有較大的差異可能是資料庫經過大量資料異動後, 資料庫的統計值不正確所導致, 可檢查自動更新統計資料是否設定為True. 並且注意這個自動統計參數的設定可分為資料庫層級, 資料表層級

亦可點選單一Table 的統計資料, 檢查其上次更新時間,若上次更新後有大量刪除或轉檔則可能是造成統計值的錯誤.
若要快速更新統計值, 可執行
USE 指定資料庫
EXEC sp_updatestats