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的组成以及它的工作原理的知识就介绍到这里了，希望本次的介绍能够对您有所帮助。