自 Oracle 10g 開始,除了 AWR 與 ADDM 這兩個功能方便 DBA 管理資料庫外,另外還有一個功能叫做 Metric。Metric 與 AWR 不同的是,AWR 主要是定時把 Dynamic Performance View 的資料 (也就是 V$ 開頭的 view) 儲存起來,用來分析過往的事件;而 Metric 主要的任務是把一些裸數據進行運算,然後再把結果呈現出來,例如 DBA 想知道資料庫的 Buffer Hit Ratio 時,如果沒有 Metric,則 DBA 需要自行撰寫 SQL 將資料加以運算才能得到想要的數據,而 Metric 所做的,就是直接提供運算好的結果,省去了 DBA 撰寫 SQL 的時間。
透過 Database Control 當中 “所有測量結果” 的選項,便可以使用系統所運算的 Metric:
例如我們想知道過去 24 小時 CPU 的使用情況,便可以透過 Metric 來呈現:
或是想要觀察過去 24 小時資料庫的 Buffer Hit Ratio,也可以透過 Metric 呈現:
Metric 的資訊也可以從 dba_hist_sysmetric_summary 中獲得,以 Oracle 11gR2 來說,總共有 158 個 Metric 可以使用:
例如要查詢過去 24 小時的 Buffer Hit Ratio 便可以使用下列 SQL 語句查詢:
透過 Metric 提供的數據,我們便可以針對一些項目設定警告臨界值 (Thresholds),當系統有狀況時,可以達到主動告警的目的,透過 Database Control 的 “測量結果和原則設定值” 項目,可以針對 Metric 來設定警告臨界值,例如設定表格空間使用率的臨界值:
設定表格空間使用率達 85% 為警告臨界值、97% 為嚴重臨界值:
接下來可以設定 e-mail 發出告警訊息,首先從 “偏好設定” 中設定電子郵件收件人:
於 “設定” 中設定 SMTP 伺服器與寄件人郵件:
最後回到 “偏好設定” 設定警告排程:
設定完排程要觸發的時段就大功告成了:
最後我們來談一下資料庫的統計資訊 (Statistics),Statistics 的使用上會與資料庫的優化器 (Optimizer) 有關,當資料庫接收到一句 SQL 語法時,便會由優化器決定它的執行計畫,目前 Oracle 資料庫的主流是以成本為基礎的優化器 (Cost Base),此時優化器需要藉由資料庫所提供的統計資訊來計算出執行計畫的成本,進而決定最佳的執行計畫,因此若資料庫缺少 Statistics ,便會影響到 SQL 的執行計畫,甚至影響效能。當優化器想知道一個 Table 裡面有多少資料時,並非使用 select count(*) 的語法來查詢,而是直接去 Data Dictionary 查找,也就是從 dba_tables 中獲取這個表格有多少資料,這些 Data Dictionary 所存放的相關資訊,就是我們說的 Statistics。
影響統計資訊蒐集與否由參數 statistics_level 所決定,statistics_level 有三種模式可以設定:
Basic : 不蒐集任何統計資訊。
Typical : 預設, 蒐集基本統計資訊 (NUM_ROWS, BLOCKS…etc) 。
ALL : 蒐集 Typical + plan execution statistics + timed OS statistics 。
一般來說使用預設的 “Typical” 設定就已足夠。
Oracle 資料庫預設每天 22:00 會進行排程來蒐集 Statistics,除此之外,也可以使用 dbms_stats 來自行蒐集,這個部分於之後的 “效能調教” 專欄上再來做詳細的探討。
沒有留言:
張貼留言