---

---

---

---

ASH (Active Session History)
ASH以V$SESSION為基礎，每秒取樣一次，記錄活動會話等待的事件。不活動的會話不會取樣，取樣工作由新引入的後臺程式MMNL來完成。
ASH buffers 的最小值為1MB,最大值不超過30MB。記憶體中記錄資料。期望值是記錄一小時的內容。

生成ASH報告：
SQLPLUS>@?/rdbms/ashrpt.sql

ASH記憶體記錄資料始終是有限的，為了儲存歷史資料，引入了自動負載資訊庫(Automatic Workload Repository ,AWR) 由後臺程式MMON完成。ASH資訊同樣被採集寫出到AWR負載庫中。由於記憶體不是足夠的，所以MMNL程式在ASH寫滿後會將資訊寫出到AWR負載庫中。ASH全部寫出是不可接受的，所以一般只寫入收集的10%的資料量，而且使用direct-path insert完成，儘量減少日誌的生成，從而最小化資料庫效能影響。

寫出到AWR負載庫的ASH資訊記錄在AWR的基礎表wrh$active_session_hist中，wrh$active_session_hist是一個分割槽表，Oracle會自動進行資料清理。

AWR(Automatic Workload Repository)自動工作負載資訊庫
AWR是Oracle 10g中的一個新特性，類似於10g以前的statspack。不過在使用上要比statspack簡單，提供的效能指標要比statspack多很多，能更好的幫助DBA來發現資料庫的效能瓶頸。
AWR是Oracle安裝好後自動啟動的，不需要特別的設定。收集的統計資訊儲存在SYSAUX表空間SYS模式下，以WRM$_*和WRH$_*的格式命名，預設會保留最近7天收集的統計資訊。每個小時將收集到的資訊寫到資料庫中，這一系列操作是由一個叫MMON的程式來完成的。

AWR儲存的資料分類：
WRM$表儲存AWR的後設資料（awrinfo.sql指令碼）
WRH$表儲存取樣快照的歷史資料（awrrpt.sql指令碼）
WRI$表儲存同資料庫建議功能相關的資料（ADDM相關資料）

一.生成AWR報告：
SQL>@?/rdbms/admin/awrrpt

根據嚮導來完成AWR報告的生成。需要注意的是，在選擇時間範圍的時候，中間不能有停機(如果顯示的時間中間有空白行，表示有停機情況)。在選擇報告型別的時候一般使用預設的HTML，方便檢視。

二.檢視資料庫的AWR的設定：
SQL> select snap_interval, retention from dba_hist_wr_control;

SNAP_INTERVAL
---------------------------------------------------------------------------
RETENTION
---------------------------------------------------------------------------
+00000 01:00:00.0(每小時收集一次)
+00007 00:00:00.0(保留7天)

三.修改預設設定：
begin
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 20,
retention => 2*24*60);
end;

修改成每20分鐘收集一次統計量，保留最近的2天統計量資訊。

四.手動收集一次資料庫的統計資訊：
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

我們還可以通過DBMS_WORKLOAD_REPOSITORY包完成對基線，預設設定的修改等操作。

ADDM (Automatic Database Diagnostic Monitor AWR)
是Oracle內部的一個顧問系統，能夠自動的完成最資料庫的一些優化的建議，給出SQL的優化，索引的建立，統計量的收集等建議。

ADDM報告生成：
SQLPLUS>@?/rdbms/addmrpt.sql

Oracle效能調整最重要的就是對最影響效能的SQL的調整。在一個應用中，能夠影響到資料庫的只有SQL，也只能是SQL。我們不能一味依靠增強硬體，修改系統、資料庫引數來提高資料庫的效能。更多的應該關注那些最影響效能的SQL語句。ASH報告、AWR報告、ADDM報告都能夠找出最影響效能的SQL的工具。在分析ASH報告、AWR報告的時候，最重要的就是關注SQL Statistics，SQL Statistics中最應該關注的是SQL ordered by Gets和SQL ordered by Reads兩個指標。大量的Gets(邏輯讀)會佔用大量的CPU時間。大量的Reads(物理讀)會引起IO的瓶頸出現。一般情況下，大量的Gets會伴隨著大量的Reads出現。當然，我們可以通過增大SGA的大小來減少Reads的量。通過這兩個指標找到了最影響效能的SQL，這是首要的，也是必要的。下一步就可以通過建立索引，調整SQL來提高SQL單獨執行時的效能。減少SQL執行時出現的高Gets,Reads。當然整體的效能影響還和excutions有關，如果這條SQL執行的次數過多，累加起來量還是很大的。那麼就可以考慮通過在應用上快取等手段來減少SQL執行的次數。另外還有一個需要注意的問題就是在開發過程中SQL一定要使用繫結變數，來減少硬解析(大量的硬解析也會消耗大量的CPU時間，佔用大量的Latch)。在開發過程中有個原則就是：小事務。操作完成及時的提交。

我們使用這麼多種方式、報告只有一個唯一的目的：找出最影響系統效能的SQL語句。找到SQL下一步就是對它進行調整了。

我們在監控資料庫時，如果是當前正在發生的問題，我們可以通過v$session+v$sqlarea來找出效能最差的SQL語句。如果在一個小時以內發生的我們可以通過生成ASH報告來找出SQL。如果是1小時以上或幾天我們可以通過AWR報告來找出幾小時，幾天以來最影響系統的SQL語句。ADDM報告基於AWR庫，預設可以儲存30天的ADDM報告。

我們也可以直接查詢試圖：
v$session                                      (當前正在發生)
v$session_wait                            (當前正在發生)
v$session_wait_history              (會話最近的10次等待事件)
v$active_session_history           (記憶體中的ASH採集資訊，理論為1小時)
wrh$_active_session_history    (寫入AWR庫中的ASH資訊，理論為1小時以上)
dba_hist_active_sess_history   (根據wrh$_active_session_history生成的檢視)

    ADDM會收集資料建議呼叫不同的Advisor進行資料庫優化，SQL相關的Advisor主要包括SQL Access Advisor和SQL Tuning Advisor。

        SQL Access Advisor和SQL Tuning Advisor之間的區別（http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1794009000346753857）：

In a nutshell - the tuning advisor 
o suggests sql profiles 
o gathering more or stale statistics 
o indexes that might be VERY useful 
o query rewrites 

the access advisor 
o suggests indexes that might be useful (a possibly different set than the tuning advisor above) 
o materialized views 
o materialized view logs 
o partitions (in 11g on up only) 

   SQL Access Advisor可以通過DBMS_ADVISOR呼叫，SQL Tuning Advisor可以通過DBMS_SQLTUNE呼叫。

參考文章：
   《More about AWR》：http://blog.itpub.net/23135684/viewspace-1127938/

--end--

For some time, Oracle’s solution in this area has been its built-in tool, Statspack.Oracle Database 10g offers a significant improvement: the Automatic Workload Repository (AWR). The AWR installs along with the database and captures not only statistics, but the derived metrics as well.

AWR retention settings and data gathering frequency

The AWR History is by default maintained for 7 days and the data is gathered in the AWR repository tables every hour by default.

The current snapshot retention settings and data gathering frequency can be determined by the query shown below. Note in this case the default settings of 7 days and 1 hour is displayed.

SQL> select to_char(snap_interval,’DD’),to_char(retention,’DD’) FROM dba_hist_wr_control;

TO_CHAR(SNAP_INTER TO_CHAR(RETENTION,
—————— ——————
+00000 01:00:00.0 +00007 00:00:00.0;

To change the settings –say, for snapshot intervals of 20 minutes and a retention period of two days –you would issue the following. The parameters are specified in minutes.

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

AWR TABLES

Metadata (WRM$)
Historical data (WRH$)
AWR tables related to advisor functions (WRI$)
Oracle 11g New Features About Workload Capture and Workload Replay tables (WRR$)

Workload Repository Reports

Oracle provide two main scripts to produce workload repository reports (awrrpt.sql and awrrpti.sql). They are similar in format to the statspack reports and give the option of HTML or plain text formats. The two reports give essential the same output but the awrrpti.sql allows you to select a single instance. The reports can be generated as follows:
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
@$ORACLE_HOME/rdbms/admin/awrrpti.sql

There are other scripts too, here is the full list:

REPORT NAME                                   SQL Script 
Automatic Workload Repository Report          awrrpt.sql 
Automatic Database Diagnostics Monitor Report addmrpt.sql 
ASH Report                                    ashrpt.sql 
AWR Diff Periods Report                       awrddrpt.sql 
AWR Single SQL Statement Report               awrsqrpt.sql 
AWR Global Report                             awrgrpt.sql 
AWR Global Diff Report                        awrgdrpt.sql  

Exporting and Importing AWR snapshot data

AWR data is stored in the WRH$ and DBA_HIST tables in the SYSAUX tablespace. There could be performance implications if these tables were to grow too large in size or if the retention was increased beyond the default of 7 days.

A good solution is to have a central repository and move statistical AWR data periodically to this central repository database using the Oracle supplied awrextr.sql and awrload.sql scripts which can be found in the $ORACLE_HOME/rdbms/admin directory.

– in source db
SQL> @?/rdbms/admin/awrextr.sql

– in target db
SQL>@?/rdbms/admin/awrload.sql

or

using oracle internal package
dbms_swrf_internal.AWR_EXTRACT
DBMS_SWRF_INTERNAL.AWR_LOAD
DBMS_SWRF_INTERNAL.MOVE_TO_AWR
DBMS_SWRF_INTERNAL.CLEAR_AWR_DBID

Clean AWR

exec dbms_swrf_internal.unregister_database();

dbms_workload_repository.DROP_SNAPSHOT_RANGE;

Disable Oracle AWR

If you would like to disable AWR from executing on an Oracle database, here are several ways to turn it off. If you are not using the AWR data, why pay the penalty for having it continually running and collecting unused data. These steps are listed in what I think are the easiest options first.

1,Set STATISTICS_LEVEL parameter to BASIC.
2,Run the CATNOAWR.sql script to drop the AWR Repository tables. The script calls procedure dbms_swrf_internal.remove_wr_control, which deletes a row relating to your database from the wrm$_wr_control table, and then drops all the AWR tables.
3,Execute DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval=>0).By setting the value of the interval as 0, we set the new interval between each snapshot collection as 110 years:
4,Download dbms_awr.plb from Metalink, compile this package and execute the PL/SQL package DBMS_AWR.DISABLE_AWR() [see Metalink note 436386.1].
5,This does not work for an existing database, but does for future databases: Create your own database creation scripts (do not utilize DBCA) and do not execute the CATAWRTB.sql script.
6,_awr_restrict_mode initialization parameter which is set to TRUE and turns off all AWR features in the repository database

Recreate the AWR

Oracle Support suggesting us to recreate the AWR using the below steps since our SYSAUX tablespace is keep growing:

alter system set sga_target=0 scope=spfile;
alter system set statistics_level = basic scope=both;
alter system set cluster_database=false;

shutdown immediate

startup restrict
– in 10g begin —
@?/rdbms/admin/catnoawr.sql
alter system flush shared_pool;
@?/rdbms/admin/catsvrm.sql –in the script had calls catawrtb.sql
– in 10g end —

– in 11g begin—
SQL> @?/rdbms/admin/catnoawr.sql
SQL> alter system flush shared_pool;
SQL> @?/rdbms/admin/catawr.sql
SQL> @?/rdbms/admin/utlrp.sql
sql> @?/rdbms/admin/execsvrm.sql
– in 11g end—

Then re-enable the AWR statistics gathering as required, by setting STATISTICS_LEVEL back to its original value, and restart the instance normally

Tip:
When SYSAUX tablespace is keep growing,you can check the V$SYSAUX_OCCUPANTS View to find out who/what is occupying space in SYSAUX.

---

---

=========================================================================================================
                                 概念知識梳理
=========================================================================================================
--->>根據時段區間生成ASH報告:

---->>ASH報告資訊:
 

ASH （Active Session History）

    ASH以V$SESSION為基礎，每秒取樣一次，記錄活動會話等待的事件。不活動的會話不會取樣，取樣工作由新引入的後臺程式MMNL來完成。

    ASH buffers 的最小值為1MB,最大值不超過30MB.記憶體中記錄資料。期望值是記錄一小時的內容。

    生成ASH報告：

    SQLPLUS>@?/rdbms/ashrpt.sql

    ASH 記憶體記錄資料始終是有限的，為了儲存歷史資料，引入了自動負載資訊庫（AutomaticWorkload Repository ,AWR） 由後臺程式MMON完成。ASH資訊同樣被採集寫出到AWR負載庫中。由於記憶體不是足夠的，所以MMNL程式在ASH寫滿後會將資訊寫出到AWR負載庫 中。ASH全部寫出是不可接受的，所以一般只寫入收集的10%的資料量，而且使用direct-pathinsert完成，儘量減少日誌的生成，從而最小 化資料庫效能影響。

    寫出到AWR負載庫的ASH資訊記錄在AWR的基礎表wrh$active_session_hist中，wrh$active_session_hist是一個分割槽表，Oracle會自動進行資料清理。

    AWR（Automatic Workload Repository）自動工作負載資訊庫

    AWR是Oracle 10g中的一個新特性，類似於10g以前的statspack.不過在使用上要比statspack簡單，提供的效能指標要比statspack多很多，能更好的幫助DBA來發現資料庫的效能瓶頸。

    AWR 是Oracle安裝好後自動啟動的，不需要特別的設定。收集的統計資訊儲存在SYSAUX表空間SYS模式下，以WRM$_*和WRH$_*的格式命名，預設會保留最近7天收集的統計資訊。每個小時將收集到的資訊寫到資料庫中，這一系列操作是由一個叫MMON的程式來完成的。
  ---->>根據snapshot敬意生成AWR報告:
  
---------->>AWR報告部分資訊:

  
AWR儲存的資料分類：

    WRM$表儲存AWR的後設資料（awrinfo.sql指令碼）

    WRH$表儲存取樣快照的歷史資料（awrrpt.sql指令碼）

    WRI$表儲存同資料庫建議功能相關的資料（ADDM相關資料）

    一。生成AWR報告：

    SQL>@?/rdbms/admin/awrrpt

    根據嚮導來完成AWR報告的生成。需要注意的是，在選擇時間範圍的時候，中間不能有停機（如果顯示的時間中間有空白行，表示有停機情況）。在選擇報告型別的時候一般使用預設的HTML,方便檢視。

    二。檢視資料庫的AWR的設定：

    SQL> select snap_interval, retention from dba_hist_wr_control;

    SNAP_INTERVAL

    ---------------------------------------------------------------------------

    RETENTION

    ---------------------------------------------------------------------------

    +00000 01:00:00.0（每小時收集一次）

    +00007 00:00:00.0（保留7天）

 三。修改預設設定：

    begin

    DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS（interval => 20,

    retention => 2*24*60）；

    end;

    修改成每20分鐘收集一次統計量，保留最近的2天統計量資訊。

    四。手動收集一次資料庫的統計資訊：

    exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

    我們還可以通過DBMS_WORKLOAD_REPOSITORY包完成對基線，預設設定的修改等操作。

    ADDM （Automatic Database Diagnostic Monitor AWR）

    是Oracle內部的一個顧問系統，能夠自動的完成最資料庫的一些優化的建議，給出SQL的優化，索引的建立，統計量的收集等建議。

    ---->>根據AWR區間生成ADDM報告：

   ---->>ADDM報告概要資訊:

ADDM報告生成：

    SQLPLUS>@?/rdbms/addmrpt.sql

    Oracle 效能調整最重要的就是對最影響效能的SQL的調整。在一個應用中，能夠影響到資料庫的只有SQL,也只能是SQL.我們不能一味依靠增強硬體，修改系統、 資料庫引數來提高資料庫的效能。更多的應該關注那些最影響效能的SQL語句。ASH報告、AWR報告、ADDM報告都能夠找出最影響效能的SQL的工具。 在分析ASH報告、AWR報告的時候，最重要的就是關注SQL Statistics,SQL Statistics中最應該關注的是SQL ordered byGets和SQL ordered byReads兩個指標。大量的Gets（邏輯讀）會佔用大量的CPU時間。大量的Reads（物理讀）會引起IO的瓶頸出現。一般情況下，大量的 Gets會伴隨著大量的Reads出現。當然，我們可以通過增大SGA的大小來減少Reads的量。通過這兩個指標找到了最影響效能的SQL,這是首要 的，也是必要的。下一步就可以通過建立索引，調整SQL來提高SQL單獨執行時的效能。減少SQL執行時出現的高Gets,Reads.當然整體的效能影 響還和 excutions有關，如果這條SQL執行的次數過多，累加起來量還是很大的。那麼就可以考慮通過在應用上快取等手段來減少SQL執行的次數。另外還有 一個需要注意的問題就是在開發過程中SQL一定要使用繫結變數，來減少硬解析（大量的硬解析也會消耗大量的CPU時間，佔用大量的Latch）。在開發過 程中有個原則就是：小事務。操作完成及時的提交。

    我們使用這麼多種方式、報告只有一個唯一的目的：找出最影響系統效能的SQL語句。找到SQL下一步就是對它進行調整了。

    我們在監控資料庫時，如果是當前正在發生的問題，我們可以通過v$session+v$sqlarea來找出效能最差的SQL語句。如果在一個小時以內發 生的我們可以通過生成ASH報告來找出SQL.如果是1小時以上或幾天我們可以通過AWR報告來找出幾小時，幾天以來最影響系統的SQL語句。ADDM報 告基於AWR庫，預設可以儲存30天的ADDM報告。

    我們也可以直接查詢試圖：

    v$session                                     （當前正在發生）

    v$session_wait                           （當前正在發生）

    v$session_wait_history             （會話最近的10次等待事件）

    v$active_session_history          （記憶體中的ASH採集資訊，理論為1小時）

    wrh$_active_session_history    （寫入AWR庫中的ASH資訊，理論為1小時以上）

    dba_hist_active_sess_history   （根據wrh$_active_session_history生成的檢視）
=========================================================================================================
                                 實 用 腳 本
=========================================================================================================

@?rdbms/admin/awrrpt.sql是以前statspack的擴充套件，收集資訊更詳細，檢視長期的資料庫情況。
@?rdbms/admin/ashrpt.sql檢視當前的資料庫情況，因為ash是每秒從v$session進行進行取樣，awr收集的資料要比ash多得多。
一般收集資料庫資訊的話要結合awr和ash。
@?rdbms/admin/addmrpt .sql相當於是駐留在oracle裡的一位專家，是一個自我診斷引擎。產生symptom，problem，infomation，提供解決問題的建議，並自動修復一些具體的故障。
@?rdbms/admin/awrinfo.sql顯示的都是awr的相關資訊，包括快照資訊、sysaux空間使用、awr元件、ash等資訊。
=========================================================================================================
                                簡   單   總    結
=========================================================================================================
awr與ash的最主要的區別在於：awr是平面的，全面的，ash是立體的，更側重於session的event跟蹤，
由於業務量大的資料庫的event wait是瞬息萬變，awr很可能會監控不到，為了彌補這個不足，ash才可以對session的event進行跟蹤。
ash與addm的區別在於：addm偶重於基於對當據庫當前狀態的分析，對存在的問題提供指導性的意見，可以說ash，addm是awr的補充，
awr全面地收集資料庫的狀態，但ash/addm是側重要對收集的資料進行分析，並提供一些有益的建議。

---

---

 在Oracle資料庫中，有時我們可能會遇到這樣的術語：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高興的是，Oracle 10g中保留下了v$session_wait中的這些資訊。

       在Oracle 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和其他幾個檢視的聯合展現，通常通過這個檢視進行歷史資料的訪問。

      上面我們介紹了Oracle資料庫ASH和AWR的簡單介紹，接下來詳細介紹一下AWR的組成以及它的工作原理

      1.ash佔用的記憶體大小

      ASH的採集資訊儲存在記憶體中，在舊的資訊被取樣到AWR中後，可被新採集的資訊覆蓋，重啟oracle後該資訊被清除。分配給ASH的記憶體大小可以查詢到：

       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$_*的格式命名。前一種型別儲存後設資料資訊（如檢查的資料庫和採集的快照），後一種型別儲存實際採集的統計資料。

       當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天。

       6.取樣資料量

       由於資料量巨大，把所有ASH資料寫到磁碟上是不可接受的。一般是在寫到磁碟的時候過濾這個資料，寫出的資料佔取樣資料的10%，寫出時通過direct-path insert完成，儘量減少日誌生成，從而最小化資料庫效能的影響。

       7.初始化引數statistics_level

       AWR的行為受到引數STATISTICS_LEVEL的影響。這個引數有三個值：

       BASIC：awr統計的計算和衍生值關閉.只收集少量的資料庫統計資訊。

       TYPICAL：預設值．只有部分的統計收集.他們代表需要的典型監控oracle資料庫的行為。

       ALL：所有可能的統計都被捕捉. 並且有作業系統的一些資訊.這個級別的捕捉應該在很少的情況下,比如你要更多的sql診斷資訊的時候才使用。

       關於Oracle資料庫AWR的組成以及它的工作原理的知識就介紹到這裡了，希望本次的介紹能夠對您有所幫助。