又是一篇好文，http://dolphin-ygj.iteye.com/blog/464478
dolphin_ygj的作品
AWR介紹與SYSAUX空間關係
2007-11-05 14:56
0、問題起源：正式庫中sysaux表空間膨脹 1）.正式庫中sysaux情況介紹: 正式庫中的sysaux表空間初始設置爲800m，上個月佔用率達到97%，警告日誌中出現SYSAUX表空間不足的信息。將其擴充到1300m。 前幾天又出現sysaux表空間不足的信息，使用率達到93%，警告日誌中出現SYSAUX表空間不足的信息。該表空間又被擴充100m，達到1400m。 目前使用率是90%，剩餘空間約120m。 2）.表空間膨脹原因 通過查詢表dba_segments，可看到該表空間中佔用空間最多的表爲：wrh$_active_session_history（約380m）及該表索引（約65m）。共計約450m。 SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, BYTES / 1024 / 1024 FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'SYSAUX'; 查詢表wrh$_active_session_history中的數據，約1680，000條記錄。 select count(*) from wrh$_active_session_history; 將該表中的數據按照event_id分組，查詢產生數據量最多的事件的event_id和event_name。 可見主要事件爲cursor: pin S wait on X（約1670，000條） SELECT A.EVENT_ID, B.NAME, COUNT(*) FROM WRH$_ACTIVE_SESSION_HISTORY A, V$EVENT_NAME B WHERE A.EVENT_ID = B.EVENT_ID GROUP BY A.EVENT_ID, B.NAME; 由此，基本找到了sysaux表空間膨脹的原因：數據庫中產生大量的“cursor: pin S wait on X”事件。 3）.如何解決“cursor: pin S wait on X”事件 用google搜索一下，目前還沒發現解決辦法。有的帖子說這是oracle這個版本的bug（http://www.itpub.net/720856.html）。 但是wrh$_active_session_history表中的數據可以減小。它的產生是由於開啓了awr（auto workload repository）。定期從活動的session中產生快照，並保存在磁盤上（表wrh$_active_session_history），有一定的保留期。 默認情況下，oracle每個1小時產生一次快照，並將其保留7天。查詢表dba_hist_wr_control可以看到： SQL> select * from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---- ------------- ----------- ---------- 1148 +00000 00:1 +00007 00:0 DEFAULT 那麼，就可以通過四種途徑解決： （1）關閉快照（影響：不會產生性能分析數據） （2）減小產生快照的頻率（影響：產生粗糙的性能分析數據） （3）減小快照在磁盤中的保留期限（影響：只能保存短期的性能分析數據）。 （4）同時使用方法2和方法3（影響：同方法2和方法3）。 4）.參考資料 oracle 10g 新特性中文筆記(第五章)：http://mugen.itpub.net/post/76/21994 oracle10g AWR[zt] http://xsb.itpub.net/post/419/308733 10gR2的wrh$_分區錶快速膨脹怎麼辦？http://xzh2000.itpub.net/post/96/210366 一、WHY——爲什麼會出現ASH和AWR？ 1. 10g之前 用戶的連接將產生會話，當前會話記錄保存在v$session中；處於等待狀態的會話會被複制一份放在v$session_wait中。當該連接斷開後，其原來的連接信息在v$session和v$session_wait中就會被刪除。這是10g之前的狀況。 2. v$session_wait_history與ASH 若是一個普通的會話（我是指沒有大量地耗費資源），則對於性能調整來說無足輕重。但若該會話在活動時大量佔用了資源（比如：CPU，內存，I/O等），該會話信息的丟失，將無法評測當時的系統瓶頸究竟是什麼。令DBA高興的是，oracle10g中保留下了v$session_wait中的這些信息。 在10g中新出現了一個視圖：v$session_wait_history。這個視圖保存了每個活動session在v$session_wait中最近10次的等待事件。但這對於一段時期內的數據庫性能狀況的監測是遠遠不夠的，爲了解決這個問題，在10g中還新添加了一個視圖：v$active_session_history。這就是ASH（active session history）。 典型的情況下,爲了診斷當前數據庫的狀態，需要最近的五到十分鐘的詳細信息。然而，由於記錄session的活動信息是很費時間和空間的，ASH採用的策略是：保存處於等待狀態的活動session的信息，每秒從v$session_wait中採樣一次，並將採樣信息保存在內存中。 3. AWR 注意，ASH的採樣數據是保存在內存中。而分配給ASH的內存空間是有限的，當所分配空間佔滿後，舊的記錄就會被覆蓋掉；而且數據庫重啓後，所有的這些ASH信息都會消失。這樣，對於長期檢測oracle的性能是不可能的。在Oracle10g中，提供了永久保留ASH信息的方法，這就是AWR（auto workload repository）。 由於全部保存ASH中的信息是非常耗費時間和空間的，AWR採用的策略是：每小時對v$active_session_history進行採樣一次，並將信息保存到磁盤中，並且保留7天，7天后舊的記錄纔會被覆蓋。這些採樣信息被保存在視圖wrh$_active_session_history中。而這個採樣頻率（1小時）和保留時間（7天）是可以根據實際情況進行調整的，這就給DBA們提供了更加有效的系統監測工具。 AWR永久地保存系統的性能診斷信息，由SYS用戶擁有。一段時間後，你可能想清除掉這些信息；有時候爲了性能診斷，你可能需要自己定義採樣頻率來獲取系統快照信息。Oracle 10g在包dbms_workload_repository中提供了很多過程，通過這些過程，你可以管理快照並設定基線(baselines)。 4. 小結 這樣，我們就知道了ASH和AWR產生的原因和功能。ASH保存了系統最新的處於等待的會話記錄，可以用來診斷數據庫的當前狀態；而AWR中的信息最長可能有1小時的延遲，所以其採樣信息並不能用於診斷數據庫的當前狀態，但可以用來作爲一段時期內數據庫性能調整的參考。 對於這些視圖間的繼承關係，eygle給出了一個關係圖： 圖1 各個視圖的層次 其中視圖dba_hist_active_sess_history是wrh$_active_session_history和其他幾個視圖的聯合展現，通常通過這個視圖進行歷史數據的訪問。 二、WHAT——什麼是AWR？ 現在我們稍微詳細地瞭解一下剛纔所說內容。 1. ash佔用的內存大小 ASH的採集信息保存在內存中，在舊的信息被採樣到AWR中後，可被新採集的信息覆蓋，重啓oracle後該信息被清除。分配給ASH的內存大小可以查詢到： SQL> select pool, name, bytes/1024/1024 From v$sgastat where name like '%ASH %'; POOL NAME BYTES/1024/1024 ------------- ------------- --------------- shared pool ASH buffers 2 2. AWR更正 爲了便於描述和理解，在第一部分中，我們說AWR就是保存ASH中的信息。 其實，AWR記錄的信息不僅是ASH，還可以收集到數據庫運行的各方面統計信息和等待信息，用以診斷分析。 AWR的採樣方式是，以固定的時間間隔爲其所有重要的統計信息和負載信息執行一次採樣，並將採樣信息保存在AWR中。 可以這樣說：ASH中的信息被保存到了AWR中的視圖wrh$_active_session_history中。ASH是AWR的真子集。 3. mmon進程與mmnl進程 快照由一個稱爲 MMON 的新的後臺進程（及其從進程）以及MMNL後臺進程自動地每隔固定時間採樣一次。我們先來看一下10g的概念指南中對這兩個新增加的後臺進程的介紹： * MMON進程負責執行多種和管理相關（manageability-related）的後臺任務，例如： * 當某個測量值（metrics）超過了預設的限定值（threshold value）後提交警告 * 創建新的 MMON 隸屬進程（MMON slave process）來進行快照（snapshot） * 捕獲最近修改過的 SQL 對象的統計信息 * MMNL進程負責執行輕量級的且頻率較高的和可管理性相關的後臺任務，例如捕獲會話歷史信息，測量值計算等。 AWR的採樣工作由MMON進程每個1小時執行一次，ASH信息同樣會被採樣寫出到AWR負載庫中。雖然ASH buffer被設計爲保留1小時的信息，但很多時候這個內存是不夠的，當ASH buffer寫滿後，另外一個後臺進程MMNL將會主動將ASH信息寫出。 4. SYSAUX表空間 這些採樣數據都存儲在SYSAUX表空間中，並且以WRM$_* 和 WRH$_*的格式命名。前一種類型存儲元數據信息（如檢查的數據庫和採集的快照），後一種類型保存實際採集的統計數據。 SQL> select table_name from dba_tables where table_name like 'WRM$%'; TABLE_NAME ----------------------- WRM$_WR_CONTROL WRM$_SNAP_ERROR WRM$_SNAPSHOT WRM$_DATABASE_INSTANCE WRM$_BASELINE 當SYSAUX表空間滿後，AWR將自動覆蓋掉舊的信息，並在警告日誌中記錄一條相關信息： ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX 5. 採樣頻率和保留時間 可以通過查詢視圖dba_hist_wr_control或（wrm$_wr_control）來查詢AWR的採樣頻率和保留時間。默認爲每1小時採樣一次，採樣信息保留時間爲7天。 SQL> select * from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---- ------------- ----------- ---------- 1148 +00000 00:1 +00007 00:0 DEFAULT SQL> select DBID, SNAP_INTERVAL, SNAPINT_NUM, RETENTION from wrm$_wr_control; DBID SNAP_INTERVAL SNAPINT_NUM RETENTION ---------- ------------------ ----------- -------------------- 1160732652 +00000 01:00:00.0 3600 +00007 00:00:00.0 6. 採樣數據量 由於數據量巨大，把所有ASH數據寫到磁盤上是不可接受的。一般是在寫到磁盤的時候過濾這個數據，寫出的數據佔採樣數據的10%，寫出時通過direct-path insert完成，儘量減少日誌生成，從而最小化數據庫性能的影響。 7. 初始化參數statistics_level AWR的行爲受到參數STATISTICS_LEVEL的影響。這個參數有三個值： * BASIC：awr統計的計算和衍生值關閉.只收集少量的數據庫統計信息. * TYPICAL：默認值．只有部分的統計收集.他們代表需要的典型監控oracle數據庫的行爲. * ALL : 所有可能的統計都被捕捉. 並且有操作系統的一些信息.這個級別的捕捉應該在很少的情況下,比如你要更多的sql診斷信息的時候才使用. 三、HOW——如何使用AWR？ AWR由ORACLE自動產生，但是也可以通過DBMS_WORKLOAD_REPOSITORY包來手工創建、刪除和修改。可以使用desc命令查看該包中的過程。下面只介紹幾個常用的： 1. 手工創建一個快照 SQL> select count(*) from wrh$_active_session_history; COUNT(*) ---------- 317 SQL> begin 2 dbms_workload_repository.create_snapshot(); 3 end; 4 / PL/SQL 過程已成功完成。 SQL> select count(*) from wrh$_active_session_history; COUNT(*) ---------- 320 2. 手工刪除指定範圍的快照 SQL> select * from wrh$_active_session_history where snap_id = 96; SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME ---------- ---------- --------------- ---------- ---------------------------- 96 1160732652 1 236930 06-10月-07 11.26.04.562 上午 96 1160732652 1 236930 06-10月-07 11.26.04.562 上午 96 1160732652 1 236930 06-10月-07 11.26.04.562 上午 SQL> begin 2 dbms_workload_repository.drop_snapshot_range(low_snap_id => 96, high_snap_id => 96, dbid => 1160732652); 3 end; 4 / PL/SQL 過程已成功完成。 SQL> select * from wrh$_active_session_history where snap_id = 96; 未選定行 3. 修改採集時間和統計信息保留時間 PROCEDURE MODIFY_SNAPSHOT_SETTINGS 參數名稱 類型 輸入/輸出默認值? ------------------------------ ----------------------- ------ -------- RETENTION NUMBER IN DEFAULT INTERVAL NUMBER IN DEFAULT TOPNSQL NUMBER IN DEFAULT DBID NUMBER IN DEFAULT 通過修改retention參數可以修改awr信息的保留期限。默認的是七天,最小的值是一天。如果把retention設置爲零,自動清除就關閉了.如果awr發現sysaux空間不夠,它通過刪除那些最老部分的快照來重新使用這些空間.同時,也會給dba發一條警告,告訴sysaux空間不夠了（在警告日誌中）. 通過修改interval參數可以修改awr信息的採樣頻率。最小的值是10分鐘,默認的是60分鐘.典型的值是10,20,30,60,120等等。把interval設爲0則關閉自動捕捉快照.如將收集間隔時間改爲30 分鐘一次。並且保留5天時間（注：單位都是爲分鐘）： SQL> select *from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---------- ------------------ -------------------------- ----------- 1160732652 +00000 01:00:00.0 +00007 00:00:00.0 DEFAULT SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60); PL/SQL 過程已成功完成。 SQL> SELECT *from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---------- ------------------- ------------------------- ----------- 1160732652 +00000 00:30:00.0 +00005 00:00:00.0 DEFAULT SQL> 4. 設置基線 基線（baseline）是一種機制,這樣你可以在重要時間的快照信息集做標記。一個基線定義在一對快照之間,快照通過他們的快照序列號識別.每個基線有且只有一對快照。 一次典型的性能調整實踐從採集量度的基準線集合、作出改動、然後採集另一個基準線集合開始。可以比較這兩個集合來檢查所作的改動的效果。在 AWR 中，對現有的已採集的快照可以執行相同類型的比較。 假定一個名稱爲 apply_interest 的高度資源密集的進程在下午 1:00 到 3:00 之間運行，對應快照 ID 95 到 98。我們可以爲這些快照定義一個名稱爲 apply_interest_1 的基準線： SQL> select *From dba_hist_baseline; 未選定行 SQL> select * from wrm$_baseline; 未選定行 SQL> exec dbms_workload_repository.create_baseline(95, 98, 'apply_interest_1'); PL/SQL 過程已成功完成。 這一操作將快照從 95 到 98 編號，作爲上面指定的基準線的一部分。查看現有的基準線： SQL> select *from dba_hist_baseline; DBID BASELINE_ID BASELINE_NAME START_SNAP_ID START_SNAP_TIME END_SNAP_ID END_SNAP_TIME ---------- ----------- ------------------------- ------------- ------------------------------------- ----------- ------------ 1160732652 1 apply_interest_1 95 06-10月-07 11.00.05.375 上午 98 06-10月-07 01.44.58.062 下午 SQL> select *from wrm$_baseline; DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID ---------- ----------- ---------------------------- ------------- ----------- 1160732652 1 apply_interest_1 95 98 SQL> 在一些調整步驟之後，我們可以創建另一個基準線 — 假設名稱爲 apply_interest_2，然後只爲那些與這兩條基準線相關的快照比較量度。 SQL> exec dbms_workload_repository.create_baseline(92, 94, 'apply_interest_2'); PL/SQL 過程已成功完成。 像這樣把快照分隔在僅僅幾個集合中有助於研究調整對於性能量度的影響。您可以在分析之後使用 drop_baseline() 來刪除基準線；快照將保留（也可級聯刪除）。此外，當清除例程開始刪除舊的快照時，與基準線相關的快照不會被清除，從而允許進行進一步的分析。 5. 刪除基線 如果要刪除一個基準線: SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_1', cascade=>false); PL/SQL 過程已成功完成。 SQL> select *from wrh$_active_session_history where snap_id in (95,96,97,98); SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME ---------- ---------- --------------- ---------- ------------------------------- 95 1160732652 1 235360 06-10月-07 10.56.29.872 上午 95 1160732652 1 235230 06-10月-07 10.54.19.857 上午 95 1160732652 1 233130 06-10月-07 10.19.19.478 上午 95 1160732652 1 232830 06-10月-07 10.14.18.859 上午 95 1160732652 1 232250 06-10月-07 10.04.38.481 上午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 97 1160732652 1 238600 06-10月-07 12.33.08.420 下午 SNAP_ID DBID INSTANCE_NUMBER SAMPLE_ID SAMPLE_TIME ---------- ---------- --------------- ---------- ------------------------------- 97 1160732652 1 238420 06-10月-07 11.50.55.686 上午 97 1160732652 1 238230 06-10月-07 11.47.45.687 上午 98 1160732652 1 239140 06-10月-07 01.42.00.976 下午 98 1160732652 1 239140 06-10月-07 01.42.00.976 下午 98 1160732652 1 239140 06-10月-07 01.42.00.976 下午 98 1160732652 1 239140 06-10月-07 01.42.00.976 下午 98 1160732652 1 239140 06-10月-07 01.42.00.976 下午 98 1160732652 1 239130 06-10月-07 01.27.04.161 下午 98 1160732652 1 239130 06-10月-07 01.27.04.161 下午 98 1160732652 1 239130 06-10月-07 01.27.04.161 下午 已選擇21行。 SQL> exec dbms_workload_repository.drop_baseline(baseline_name=>'apply_interest_2', cascade=>true); PL/SQL 過程已成功完成。 SQL> select *from wrh$_active_session_history where snap_id in (92,93,94); 未選定行 SQL> 6. 生成報表 awr有個報表生成機制,可以對存儲在workload資料庫的統計產生彙總報表。這個分析對一段時間的統計做的。這個報表生成機制很像statspack。 可以使用腳本awrrpt.sql或awrrpti.sql來查看AWR報告（非常類似statspack中的spreport.sql），這兩個腳本都在目錄$ORACLE_HOME/rdbms/admin中。Awrrpt.sql腳本可以顯示指定快照id範圍的診斷信息，報告可以保存爲文本文件或HTML文件；awrrpti.sql腳本與awrrpt.sql類似，唯一的不同就是在awrrpti.sql腳本中，你可以指定數據庫ID和實例ID（作爲參數）。報告包括如下診斷信息： [1] Report summary [1] Wait events statistics [1] SQL statistics [1] Instance activity statistics [1] I/O statistics [1] Buffer pool statistics [1] Advisory statistics [1] Wait statistics [1] Undo statistics [1] Latch statistics Segment statistics [1] Dictionary cache statistics [1] Library cache statistics [1] SGA statistics [1] Resource limit statistics [1] init.ora parameters 通過運行$ORACLE_HOME/rdbms/admin目錄中的awrrpt.sql腳本，AWR的功能可以立即通過它從採集的統計數據和量度中生成的報表得到最好的說明。這個腳本顯示所有的現有AWR快照並請求兩個特定的快照作爲時間間隔邊界。它產生兩種類型的輸出：文本格式（類似於Statspack報表的文本格式但來自於AWR信息庫）和默認的HTML格式（擁有到部分和子部分的所有超鏈接），從而提供了非常用戶友好的報表。 運行這個腳本必須要select any dictionary權限.這個腳本提示你輸入選項如怎麼和在哪裏生成這個報表: *首先,你需要指明你要生成html還是text格式的 *要選擇快照的天數:輸入天數,和你最近的快照,可選的,你可以使用dba_hist_snapshot表來看你要用哪個snap_id. *開始snap_id和終止snap_id,這個快照對定義你的報表產生的時間間隔. *文件名稱,報告寫的用戶指定的文件. 現在運行該腳本以查看報表，從而對AWR的報表功能有一個直觀的瞭解。 SQL> @D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\awrrpt.sql Current Instance ~~~~~~~~~~~~~~~~ DB Id DB Name Inst Num Instance ----------- ------------ -------- ------------ 1160732652 ORCL 1 orcl Specify the Report Type ~~~~~~~~~~~~~~~~~~~~~~~ Would you like an HTML report, or a plain text report? Enter 'html' for an HTML report, or 'text' for plain text Defaults to 'html' 輸入 report_type 的值: Type Specified: html Instances in this Workload Repository schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB Id Inst Num DB Name Instance Host ------------ -------- ------------ ------------ ------------ * 1160732652 1 ORCL orcl YUECHAOTIAN Using 1160732652 for database Id Using 1 for instance number Specify the number of days of snapshots to choose from ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Entering the number of days (n) will result in the most recent (n) days of snapshots being listed. Pressing <return> without specifying a number lists all completed snapshots. 輸入 num_days 的值: 4 Listing the last 4 days of Completed Snapshots Snap Instance DB Name Snap Id Snap Started Level ------------ ------------ --------- ------------------ ----- orcl ORCL 81 04 10月 2007 07:24 1 83 05 10月 2007 13:34 1 84 05 10月 2007 16:19 1 85 05 10月 2007 17:00 1 86 05 10月 2007 18:00 1 87 05 10月 2007 19:10 1 88 05 10月 2007 20:00 1 89 05 10月 2007 21:00 1 90 05 10月 2007 22:00 1 91 05 10月 2007 23:00 1 95 06 10月 2007 11:00 1 97 06 10月 2007 13:27 1 98 06 10月 2007 13:44 1 99 06 10月 2007 14:00 1 100 06 10月 2007 14:30 1 101 06 10月 2007 15:00 1 102 06 10月 2007 15:30 1 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 輸入 begin_snap 的值: 100 Begin Snapshot Id specified: 100 輸入 end_snap 的值: 102 End Snapshot Id specified: 102 Specify the Report Name ~~~~~~~~~~~~~~~~~~~~~~~ The default report file name is awrrpt_1_100_102.html. To use this name, press <return> to continue, otherwise enter an alternative. 輸入 report_name 的值: Using the report name awrrpt_1_100_102.html <HTML><HEAD><TITLE>AWR Report</TITLE> ……（省略結果） End of Report </BODY></HTML> Report written to awrrpt_1_100_102.html SQL> 將產生的HTML腳本粘貼出來，用IE打開看看：一個指定時間段的完整的數據庫性能報告就展現在我們面前了。下面是部分截圖： 圖2 AWR報告截圖 7. statspack和awr 在過去,你可以手工的使用statspack來獲得歷史數據.你也可以繼續在oracle10g中使用statspack,但是如果你要使用workload資料庫,那你需要更改你的應用程序代碼。statspack用戶應該轉到10g的workload 資料庫。 這裏不支持數據從statspack移植到workload資料庫.同樣,也沒有視圖來模擬statspack. 在rac環境,每個快照包含集羣的所有的節點.每個節點的快照數據有相同的snap_id,但靠實例id來區分。一般地,rac中的快照是在同一時間捕捉的。 你也可以使用db control來進行手工的快照。手工的快照支持系統產生的自動快照。手工的快照可以自定義在你要捕捉的系統行爲的兩個時間點跟自動的不一致的時候，從而擁有更大的靈活性。 |