10G新特性 - AWR

使用10G新特性來收集資料庫效能統計和度量資料來分析和調優。顯示資料的確切執行時間，以及儲存的會話訊息。
　　10G的效能分析新特性
　　當資料庫發生了效能問題時，如何去定位？比較常用的方法是採用一個既定的模式：處理諸如“是不是同一問題的再現？”、“能否在某一特殊時間段發生？”、“兩個問題之間能否具有聯絡？”等問題，這樣通常能得到一個比較好的診斷結果。做為一個DBA，你可能使用一個第三方或者本人開發的工具來收集資料庫執行期間的精細統計資料，並從中得到效能度量資料。你需要將這些發生問題時的度量資料與當前資料進行比較。重現以前的時間能使現在的問題變得明朗。因而，持續的收集相關統計資料對於效能分析來說十分重要。在某些情況下，在處理收集統計資料這方面的問題上有本人內建的工具——statspack。雖然在某些情況下的做用非常大，但它缺乏處理效能問題所必須的健壯性。提供了一個標誌性的改進特性：自動工做量儲存（Automatic Workload Repository AWR）。AWR是隨著資料庫一起被安裝的，它不只能收集統計資料，還能從統計資料中分析出度量資料。
　　透過執行$ORACLE_HOME/rdbms/admin目錄下的awrrpt.sql能夠生產AWR從統計和度量資料中分析演講。這個分析演講最能體現出AWR的效能分析能力。這個指令碼看起來很像statspack，它會列出所有可用的AWR快照並要求輸入兩個特定的快照編號做為一個間隔段。它能產生兩種型別的輸出：文字格式（除了AWR統計訊息外和statspack演講基本類似）和預設的格式（透過超連線等方式來提供一個友好的介面）。下面來執行以下這個指令碼，對它產生的分析演講及AWR的效能分析能力做一個認識。

　　AWR的使用
　　首先來了解一下AWR是如何設想的，並瞭解一下它的構造。基本上來說，AWR應該是一個Oracle用來收集效能相關統計資料並從中得出效能度量資料來追蹤潛在問題的內建工具。和statspack不一樣，AWR的快照訊息是由一個新的後臺程式MMON及其執行緒來每隔一個小時自動收集的。為了節省空間，這些收集的資料會在7天后自動清除。快照收集的頻次和保留時間都是能夠被使用者修改的。能夠透過以下指令碼檢視當前的設定： SQL> select snap_interval, retention from dba_hist_wr_control;
　　　SNAP_INTERVAL RETENTION
　　　------------------- -------------------
　　　+00000 01:00:00.0 +00007 00:00:00.0
　　這個結果表明當前的快照是每隔一個小時收集一次，並且會被保留7天。要改變這個設定，比如需要設定成每隔半小時收集一次，並且只保留3天，能夠使用以下語句（引數的單位都是分）： SQL> begin
　　　2 dbms_workload_repository.modify_snapshot_settings (
　　　3 interval => 30,
　　　4 retention => 3*24*60
　　　5 );
　　　6 end;
　　　SQL> select snap_interval, retention from dba_hist_wr_control;
　　　SNAP_INTERVAL RETENTION
　　　------------------- -------------------
　　　+00000 00:30:00.0 +00003 00:00:00.0
　　AWR使用多個表來儲存收集的統計資料，它們都被放置在SYS這個方案中，儲存在一個新的特殊表空間SYSAUX上，並且以WRM$_*和WRH$_*的格式儲存。前面一種格式的表儲存諸如資料庫檢查和採集的快照等後設資料訊息，而後面一種格式的表儲存了實際收集的統計資料（M表示“Metadata後設資料”，H表示“Historical歷史”）。另外還有多個以“DBA_HIST_”為字首，由這些表構造出的檢視。你能夠利用這些檢視寫出本人的效能分析工具。這些檢視的命名與它相關的表間接相關。比如，檢視DBA_HIST_SYSMETRIC_SUMMAY是以表WRH$_SYSMETRIC_SMMURY為基礎構造的。
　　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每秒使用情況”的度量項。這條記錄能夠和其他表如“DBA_HIST_SYSMETRIC_SUMMARY”聯合查詢來起做用： SQL> 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
　　　… …
　　這顯示的是以釐秒為單位的CPU消耗時間。在分析資料中的標準偏差（Standard Deviation SD）能夠協助我們來確定平均資料圖能否反映實際工組負荷。在第一條記錄中，平均值是每秒鐘CPU消耗3釐秒，而標準偏差是9.81，這說明平均為3並沒有反映出實際工做負荷。在第二條記錄中，平均值是28，而標準偏差是5.9，所以這條記錄更具代表性。這種型別的訊息有助於協助理解在效能度量中的幾個環境引數的做用。 　使用這些統計資料
　　上面我們瞭解了AWR是如何收集統計資料的，下面就來了解以下如何利用這些資料。大多數效能問題並非孤立的，但是也不要相信哪些能夠找出問題的最終根源的流言。讓我們來做一個典型的調優練習：你發覺系統變得很慢，決定檢查一下等待事件。透過檢查發覺，“快取忙等待（buffer busy wait）”非常高。如何處理這個問題呢？具有幾種可能：可能是索引的單一增長引起的；某張表飽和了，需要立即轉載一個資料塊到記憶體中；以及其他的原因引起的。在任何情況下，你都需要先定位出發生問題的段。如果它是一個索引段，你能夠決定能否重建索引、把索引改為相反鍵索引、或者將索引轉換為在Oracle 10G特有的雜湊分割槽索引。如果是一張表，能夠考慮修改表的儲存引數使它密度降低，或者將它轉移到一個自動段空間管理的表空間上去。你的這些計劃、措施一般都是系統的，並且是基於你對各種事件的瞭解和你在處理這些問題所積累的經驗。想向一下，如果這些事情是由機器驅動來完成——這個驅動能捕捉度量資料並且在基於預先定義的邏輯能演繹出可能的計劃、措施，那麼你的工做不是能變得很輕鬆嗎？
　　現在Oracle 10G就提供了這樣的驅動，它就是自動資料庫診斷監視器（Automatic Database Diagnostic Monitor ADDM）。ADDM使用AWR收集的資料來達到那樣的效果。在上述的例子中，ADDM能夠發覺發生了buffer busy waits，找出適當的資料來檢查在哪個段上面發生的，計算出它的本來資料和混合資料，並最終為DBA提供處理辦法。每當AWR收集了一個快照資料，ADDM就會檢查這些度量資料，併產生出相應建議。因而，你就擁有了一個全天候工做的機器人DBA來為你分析資料、提前為你給出建議，讓你由更多的時間來關心戰略問題。透過使用新的10G企業管理器平臺——DB Home——能夠檢視ADDM的建議和AWR儲存的資料。你能夠從管理介面的導航器上檢視AWR的演講、負荷資料以及快照訊息。將來能夠安裝更多元件來在更多細節上來檢查ADDM。
　　你還能夠指定在特定條件下產生告警訊息。這些告警，如伺服器產生的告警（Server Generated Alerts），會被推入一個高階佇列。在任意一個客戶端上能夠監聽這個佇列。一種客戶端就是10G企業管理器，在上面能夠顯著的顯示出告警訊息。
　　時間模型
　　當你遇到一個效能問題時，首先想起降低哪個響應時間呢？你當然希望能消除或降低引起問題的最終因素的時間。但是你怎麼才能知道時間被消耗在哪呢——不是等待，而是實際的工做時間？
　　Oracle 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還能顯示其他很多統計資料，如消耗在不同型別的語句分析（Parsing）上的時間，以至PL/SQL的編譯時間。
　　這個檢視顯示的整個系統的時間模型。但是你可能對更細粒度上的檢視感興趣：會話級的時間模型。檢視V$SESS_TIME_MODEL能顯示在會話級捕捉到的時間統計資料。這些資料統計的是當前的會話，包括所有的活動的和不活動的都可見。多出的欄位SID表明了所統計的會話的SID。
　　在Oracle的以前版本，這些資料根本無法獲取到，需要使用者從各種其他資料中猜測出來。在Oracle 10g中，獲取這些資料幾乎是小菜一碟。活動會話歷史
　　檢視V$SESSION在oracle 10G中被增強了，其中最有價值的一項增強就是包括了等待時間和他們持續的時間，而不需要透過V$SESSION_WAIT來檢視了。然而，因為這個檢視很少反映出真實的時間值，所以一些重要訊息就丟失了。例如，如果你從這個檢視中查詢看能否具有某個會話在等待某個非空閒的事件，而如果這個事件的資料具有問題，你將無法找到你想要的東西，因為等待事件必須依賴於你所查詢到的時間資料。Oracle 10G的另一個特性活動會話歷史（Active Session History 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的欄位能夠幫你對某個特定的等待事件進行深入定位。例如，如果這些會話等待的事件中有一個是buffer busy wait，那就必須再做適當的診斷來定位是在哪個段上發生了等待事件。你能夠透過將ASH檢視中的CURRENT_OBJ#欄位與DBA_OBJECTS連線查詢來查到發生問題的段。
　　ASH還記錄了並行查詢服務的會話訊息，這些訊息對於診斷並行查詢的等待事件很有用。如果記錄的是並行查詢的從程式的訊息，協同服務會話的SID會被表示在QC_SESSION_ID欄位中。欄位SQL_ID記錄了產生等待事件的SQL語句的ID，透過將它與檢視V$SQL聯合查詢，能夠找出這個令人討厭的SQL語句。CLIENT_ID能夠使在如web應用這樣的共享使用者環境中更容易定位是哪個客戶端，這個欄位能夠透過儲存過程DBMS_SESSION.SET_IDENTIFIER來設定。
　　既然ASH的訊息如此有價值，那麼不是把它的資料像AWR一樣永久的儲存起來不是更好嗎？MMON程式會將這些訊息儲存到磁碟以服務於AWR表，並且能夠透過檢視DBA_HIST_ACTIVE_SESS_HISTORY來查詢。
　　手工收集
　　在預設情況下，這些快照訊息是自動收集的。但是你也能夠隨時手工收集。所有的AWR的功能都能夠透過包DBMS_WORKLOAD_REPOSITORY來實現。要產生一個快照，只需執行：exec 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的快照做為名為“apply_interest_1”的基準線的一部分。
　　用以下語句檢查已經具有的基準線： SQL> 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_baselin()來刪除這些基準線，而快照還是會被保留。同樣的，當清除規則需要清除掉舊的快照訊息時，與這些舊快照訊息相關的基準線不會被清除，以便於以後的進一步深入分析。

詳細文章參考：