為 DBA 提供的最佳前 20 位的特性 -轉

自動工作負載資訊庫

學習使用新的特性，這些特性採集資料庫效能統計資料和量度，以供分析和調整，並顯示在資料庫中花費的準確時間，甚至儲存會話資訊

當您有資料庫效能問題時，要解決它您首先要作的是什麼？一種常見的方法是看是否存在一種模式：回答諸如“相同的問題是否重複出現？”，“它是否在某個特定的時間段出現？”和“兩個問題之間是否有聯絡？”之類的問題，將幾乎總會帶來更好的診斷結果。

作為一個資料庫管理員，您可能已經投資購買了第三方工具或使用自己開發的工具來在資料庫執行期間採集詳細 的統計資料，並從這些統計資料中匯出獲得效能量度。在緊急的情況下，您可以訪問這些量度來與當前的情況作比較。再度檢視這些過去的事件可以給當前的問題帶 來一些啟發，因此不斷採集相關的統計資料對於效能分析變得很重要。

[@more@]

一段時間以來，Oracle 在這個領域中的解決方案是它內建的工具 Statspack。雖然某些情況下證明它是非常有價值的，但常常缺少效能故障診斷實踐所需的強健性。Oracle Database 10g 提供了一個顯著改進的工具：自動工作負載資訊庫 (AWR)。AWR 和資料庫一起安裝，不但採集統計資料，還採集匯出的量度。

快速測試驅動程式

透過執行 $ORACLE_HOME/rdbms/admin 目錄中的 awrrpt.sql 指令碼，AWR 的功能可以立即透過它從採集的統計資料和量度中生成的報表得到最好的說明。這個指令碼從外觀和感覺上類似於 Statspack，它顯示所有的現有 AWR 快照並請求兩個特定的快照作為時間間隔邊界。它產生兩種型別的輸出：文字格式（類似於 Statspack 報表的文字格式但來自於 AWR 資訊庫）和預設的 HTML 格式（擁有到部分和子部分的所有超連結），從而提供了非常使用者友好的報表。現在執行該指令碼以檢視報表，從而對 AWR 的功能有一個瞭解。

實施

現在，讓我們來看看 AWR 是如何設計和構建的。AWR 實質上是一個 Oracle 的內建工具，它採集與效能相關的統計資料，並從那些統計資料中匯出效能量度，以跟蹤潛在的問題。與 Statspack 不同，快照由一個稱為 MMON 的新的後臺程式及其從程式自動地每小時採集一次。為了節省空間，採集的資料在 7 天后自動清除。快照頻率和保留時間都可以由使用者修改。要檢視當前的設定，您可以使用下面的語句：

select snap_interval, retention
from dba_hist_wr_control;

SNAP_INTERVAL       RETENTION
------------------- -------------------
+00000 01:00:00.0   +00007 00:00:00.0

這些 SQL 語句顯示快照每小時採集一次，採集的資料保留 7 天。要修改設定 — 例如，快照時間間隔為 20 分鐘，保留時間為兩天 — 您可以發出以下命令。引數以分鐘為單位。

begin
   dbms_workload_repository.modify_snapshot_settings (
      interval => 20,
      retention => 2*24*60
   );
end;

AWR 使用幾個表來儲存採集的統計資料，所有的表都儲存在新的名稱為 SYSAUX 的特定表空間中的 SYS 模式下，並且以 WRM$_* 和 WRH$_* 的格式命名。前一種型別儲存後設資料資訊（如檢查的資料庫和採集的快照），後一種型別儲存實際採集的統計資料。（您可能已經猜到，H 代表“歷史資料 (historical)”而 M 代表“後設資料 (metadata)”。）在這些表上構建了幾種帶字首 DBA_HIST_ 的檢視，這些檢視可以用來編寫您自己的效能診斷工具。檢視的名稱直接與表相關；例如，檢視 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上構建的。

AWR 歷史表採集的資訊比 Statspack 多許多，這些資訊包括表空間使用率、檔案系統使用率、甚至作業系統統計資料。這些表的完整的列表可以透過以下命令從資料字典中看到：

select view_name from user_views where view_name like 'DBA_HIST_%' escape '';

檢視 DBA_HIST_METRIC_NAME 定義 AWR 採集到的重要的量度、它們所屬的組和採集它們的單位。例如，下面是一個記錄（豎直格式）：

DBID                  : 4133493568
GROUP_ID              : 2
GROUP_NAME            : System Metrics Long Duration
METRIC_ID             : 2075
METRIC_NAME           : CPU Usage Per Sec
METRIC_UNIT           : CentiSeconds Per Second 

它顯示一個量度“每秒 CPU 使用率”以“每秒的釐秒數”為單位進行測量，並且該量度屬於一個量度組 “System Metrics Long Duration”。這條記錄可以和其它的表（如 DBA_HIST_SYSMETRIC_SUMMARY）結合，以獲得資料庫的活動資訊，形式如下：

select begin_time, intsize, num_interval, minval, maxval, average, standard_deviation sd 
from dba_hist_sysmetric_summary where metric_id = 2075;

BEGIN    INTSIZE NUM_INTERVAL   MINVAL  MAXVAL  AVERAGE           SD
----- ---------- ------------   ------- ------- --------  ----------
11:39     179916           30         0      33        3  9.81553548
11:09     180023           30        21      35       28  5.91543912

... and so on ...

下面我們看看 CPU 時間是如何消耗的（以釐秒為單位）。標準差加入到了我們的分析中，它有助於確定平均數字是否反映了實際的工作負載。在第一條記錄中，平均值是每秒消耗 CPU 時間 3 釐秒，但標準差是 9.81，這意味著平均值 3 不能反映工作負載。在第二個例子中，平均值為 28，標準差為 5.9，這更具有代表性。這種型別的資訊趨勢有助於瞭解幾個環境引數對效能量度的影響。

使用統計資料

迄今為止，我們看到了 AWR 所採集的內容，現在讓我們看看它將如何處理資料。

大多數效能問題並不是孤立存在的，而留有指示性的跡象，這些跡象將通向問題最終的根源。讓我們使用一個典 型的調整實踐來說明這一點：您注意到系統很慢，於是決定檢視等待的原因。您檢查發現“緩衝區忙等待”非常高。問題可能出在哪裡呢？有幾種可能：可能有一個 單調增加的索引，可能一個表太滿了，以至於要求將單個資料塊非常快速地載入到記憶體中，或其它一些因素。無論在哪種情況下，您都首先要確定存在問題的段。如 果它是一個索引段，那麼您可以決定重新構建它，把它修改為一個反向鍵索引，或把它轉換成一個在 Oracle Database 10g 中引進的雜湊分割槽索引。如果它是一個表，您可以考慮修改儲存引數來使它不那麼密集，或者利用自動段空間管理把它轉移到一個表空間中。

您的處理計劃一般是有規律的，並且通常基於您對各種事件的瞭解和您處理它們的經驗。現在設想相同的事情由一個引擎來完成，這個引擎採集量度並根據預先確定的邏輯來推出可能的計劃。您的工作不就變得更輕鬆了嗎？

現在在 Oracle Database 10g 中推出的這個引擎稱為自動資料庫診斷監控程式 (ADDM)。為了作出決策，ADDM 使用了由 AWR 採集的資料。在上面的討論中，ADDM 可以看到發生了緩衝區忙等待，然後取出相應的資料來檢視發生緩衝區忙等待的段，評估其特性和成分，最後為資料庫管理員提供解決方案。在 AWR 進行的每一次快照採集之後，呼叫 ADDM 來檢查量度並生成建議。因此，實際上您擁有了一個一天二十四小時工作的自動資料庫管理員，它主動地分析資料並生成建議，從而把您解放出來，使您能夠關注更 具有戰略意義的問題。

要檢視 ADDM 建議和 AWR 資訊庫資料，請使用在名稱為 DB Home 的頁面上的新的 Enterprise Manager 10g 控制檯。要檢視 AWR 報表，您可以從管理轉至工作負載資訊庫，然後轉至 Snapshots 來檢視它們。在以後的部分中，我們將更詳細地討論 ADDM。

您還可以指定根據特定的情況來生成警報。這些警報稱為伺服器生成警報，它們被推送到高階佇列中，在其中它們可以被任意監聽它的客戶端使用。一個這樣的客戶端是 Enterprise Manager 10g，在其中警報被突出顯示。

時間模型

當您有效能問題時，要縮短響應時間您最先想到的是什麼？很明顯，您希望消除（或減少）增加時間的因素的根源。您如何知道時間花費在哪裡 — 不是等待，而是真正在進行工作？

Oracle Database 10g 引進了時間模型，以確定在各個地方花費的時間。花費的總的系統時間記錄在檢視 V$SYS_TIME_MODEL 中。下面是查詢和輸出結果。

STAT_NAME                                     VALUE
-------------------------------------         --------------
DB time                                       58211645
DB CPU                                        54500000
background cpu time                           254490000
sequence load elapsed time                    0
parse time elapsed                            1867816
hard parse elapsed time                       1758922
sql execute elapsed time                      57632352
connection management call elapsed time       288819
failed parse elapsed time                     50794
hard parse (sharing criteria) elapsed time    220345
hard parse (bind mismatch) elapsed time       5040
PL/SQL execution elapsed time                 197792
inbound PL/SQL rpc elapsed time               0
PL/SQL compilation elapsed time               593992
Java execution elapsed time                   0
bind/define call elapsed time                 0 

注意名稱為 DB Time 的統計量，它代表自從例程啟動起在資料庫中花費的時間。執行示例工作負載，並再次從檢視中選中統計值。統計值的差異將代表該工作負載在資料庫中花費的時 間。在又一個調整回合之後，執行相同的分析，統計值的差異將顯示在調整之後 DB Time 的變化，這可以與第一次修改進行比較，以檢視調整動作對資料庫時間的影響。

除資料庫時間之外，V$SYS_TIME_MODEL 檢視顯示了很多其它的統計量，如在不同型別的分析，甚至在 PL/SQL 編譯中花費的時間。

這個檢視還顯示了總的系統時間，不過您可能對一個更加詳細的檢視感興趣：會話級時間。時間統計資料還在會話級進行採集，如檢視 V$SESS_TIME_MODEL 中所示，在其中可以看到當前連線的會話（活動和不活動的）的所有統計資料。額外的列 SID 指示顯示的統計資料的會話的 SID。

在早期的版本中，這種分析是不可能得到的，使用者被迫進行猜測或從各種來源進行分析。在 Oracle Database 10g 中，獲得這種資訊輕而易舉。

活動會話歷史

Oracle Database 10g 中的檢視 V$SESSION 得到了改善；所有這些改善中最有價值的是包含了等待事件和它們的持續時間，從而不再需要檢視檢視 V$SESSION_WAIT。不過，因為這個檢視只反映實時的值，所以當稍後檢視它時，一些重要的資訊丟失了。例如，如果您選擇從這個檢視中檢查是否有 任何會話在等待任何非空閒的事件，如果有的話，調查這個事件，您可能發現不了任何東西，因為到您選中它的時候等待一定已經結束了。

進入新的特性活動會話歷史 (ASH)，它類似於 AWR，在一個緩衝區中儲存會話效能統計資料，以便稍後進行分析。不過，與 AWR 不同，儲存不是永久性地在一個表中進行，而是在記憶體中進行，並在檢視 V$ACTIVE_SESSION_HISTORY 中顯示。資料每秒輪詢一次，並且只有輪詢活動會話。隨著時間進行，舊的專案在一個迴圈緩衝區中被刪除，以容納新的專案，並且這些舊的專案將在檢視中顯示。要找出有多少個會話在等待某些事件，您可以使用下面的命令

select session_id||','||session_serial# SID, n.name, wait_time, time_waited
from v$active_session_history a, v$event_name n
where n.event# = a.event#

這條命令告訴您事件的名稱和等待花費了多少時間。如果您想要深入調查某個特定的等待事件，ASH 的額外的列也將幫助您實現這一目的。例如，如果會話等待的事件之一是緩衝區忙等待，那麼正確的診斷必須指出發生等待事件的段。您可以從 ASH 檢視列 CURRENT_OBJ# 中獲得這一資訊，然後該列可以和 DBA_OBJECTS 結合，以獲得存在問題的段。

ASH 還記錄並行查詢伺服器會話，這對診斷並行查詢等待事件非常有用。如果記錄是針對一個並行查詢從屬程式，那麼協調伺服器會話的 SID 由 QC_SESSION_ID 列指定。列 SQL_ID 記錄產生等待事件的 SQL 語句的 ID，該列可以和 V$SQL 檢視結合，以獲取存在問題的 SQL 語句。為了方便一個共享使用者環境（如 web 應用程式）中的客戶端的識別，也顯示了 CLIENT_ID 列，這可以由 DBMS_SESSION.SET_IDENTIFIER 來設定。

既然 ASH 資訊這麼有價值，那麼如果以一種類似於 AWR 的永久方式來儲存這種資訊不是很好嗎？幸運的是，它是以這種方式來進行儲存的；由 MMON 從程式將資訊重新整理到 AWR 表中，從而儲存在磁碟上，並且資訊可以透過檢視 DBA_HIST_ACTIVE_SESS_HISTORY 來檢視。

人工採集

快照預設是自動採集的，但您也可以按需要採集它們。所有的 AWR 功能都在程式包 DBMS_WORKLOAD_REPOSITORY 中實施。要採集一次快照，只需發出下面的命令：

execute dbms_workload_repository.create_snapshot

它立即採集一次快照，快照被記錄在表 WRM$_SNAPSHOT 中。採集的量度是針對 TYPICAL 級別的。如果您想採集更詳細的統計資料，您可以在上面的過程中將引數 FLUSH_LEVEL 設定為 ALL。統計資料自動刪除，但也可以透過呼叫過程 drop_snapshot_range() 來手動刪除。

基準線

一次典型的效能調整實踐從採集量度的基準線集合、作出改動、然後採集另一個基準線集合開始。可以比較這兩 個集合來檢查所作的改動的效果。在 AWR 中，對現有的已採集的快照可以執行相同型別的比較。假定一個名稱為 apply_interest 的高度資源密集的程式在下午 1:00 到 3:00 之間執行，對應快照 ID 56 到 59。我們可以為這些快照定義一個名稱為 apply_interest_1 的基準線：

exec dbms_workload_repository.create_baseline (56,59,'apply_interest_1')

這一操作將快照從 56 到 59 編號，作為上面指定的基準線的一部分。檢視現有的基準線：

select * from dba_hist_baseline;

      DBID BASELINE_ID BASELINE_NAME        START_SNAP_ID END_SNAP_ID
---------- ----------- -------------------- ------------- -----------
4133493568           1 apply_interest_1                56          59

在一些調整步驟之後，我們可以建立另一個基準線 — 假設名稱為 apply_interest_2，然後只為那些與這兩條基準線相關的快照比較量度。像這樣把快照分隔在僅僅幾個集合中有助於研究調整對於效能量度的影響。您可以在分析之後使用 drop_baseline() 來刪除基準線；快照將保留。此外，當清除例程開始刪除舊的快照時，與基準線相關的快照不會被清除，從而允許進行進一步的分析。

結論

這一部分的目的只是介紹 AWR 非常基本的方面。關於更完整的內容，請參見 Oracle Database 10g 文件。此外，關於 AWR 和 ADDM 的一個極好的論述可以在技術白皮書中找到。在第 15 周，您將瞭解到關於 ADDM 及使用它來解決實際問題的更多內容，。