Oracle性能調整的三把利劍--ASH,AWR,ADDM

Oracle性能調整的三把利劍--ASH,AWR,ADDM

---

---

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的組成以及它的工做原理的知識就介紹到這裏了，但願本次的介紹可以對您有所幫助。