AWR 简介

原文转自：http://blog.csdn.net/tianlesoftware/article/details/4682300

AWR的由来：
10g之前的oracle:用户的连接将产生会话，当前会话记录保存在v$session中；处于等待状态的会话会被复制一份放在v$session_wait中。当该连接
断开后，其原来的连接信息在v$session和v$session_wait中就会被删除;oracle10g及之后保留下了v$session_wait中的这些信息，并多了
v$active_session_history（ASH）视图，记录每个活动session在v$session_wait中最近10次的等待事件。

ASH的采样数据是保存在内存中。而分配给ASH的内存空间是有限的，当所分配空间占满后，旧的记录就会被覆盖掉；而且数据库重启后，所有的这些
ASH信息都会消失。这样，对于长期检测oracle的性能是不可能的。在Oracle10g中，提供了永久保留ASH信息的方法，这就是AWR。

由于全部保存ASH中的信息是非常耗费时间和空间的，AWR采用的策略是：每小时对v$active_session_history进行采样一次，并将信息保存到磁盘
中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在视图wrh$_active_session_history中。而这个采样频率（1小时）和保留时间
（7天）是可以根据实际情况进行调整的，这就给DBA们提供了更加有效的系统监测工具。

一. AWR 说明

Oracle 10g之前对数据库做性能检测使用statspack工具。 关于statspack的说明，参考我的Blog：

statspack安装使用和 report 分析

http://andyniu.iteye.com/admin/blogs/1766910

 

Oracle Database 10g 提供了一个新的工具：(AWR:Automatic Workload Repository)。Oracle 建议用户用这个取代 Statspack。AWR 实质上是一个 Oracle 的内置工具，它采集与性能相关的统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题。

与 Statspack 不同，快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间，采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。它产生两种类型的输出：文本格式（类似于 Statspack 报表的文本格式但来自于 AWR 信息库）和默认的 HTML 格式（拥有到部分和子部分的所有超链接），从而提供了非常用户友好的报表。

 

AWR 使用几个表来存储采集的统计数据，所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下，并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”。

在这些表上构建了几种带前缀 DBA_HIST_ 的视图，这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关；例如，视图DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。

 

注意一点：

statistics_level 默认是typical，在10g中表监控是激活的，强烈建议在10g中此参数的值是typical。如果STATISTICS_LEVEL设置为basic，不仅不能监控表，而且将禁掉如下一些10g的新功能：
ASH(Active Session History)
ASSM(Automatic Shared Memory Management)
AWR(Automatic Workload Repository)
ADDM(Automatic Database Diagnostic Monitor)

 

在Oracle 11gR2里禁用的功能如下：

 

STATISTICS_LEVEL specifies the level of collection for database and operating system statistics. The Oracle Database collects these statistics for a variety of purposes, including making self-management decisions.

The default setting of TYPICAL ensures collection of all major statistics required for database self-management functionality and provides best overall performance. The default value should be adequate for most environments.

When the STATISTICS_LEVEL parameter is set to ALL, additional statistics are added to the set of statistics collected with the TYPICAL setting. The additional statistics are timed OS statistics and plan execution statistics.

Setting the STATISTICS_LEVEL parameter to BASIC disables the collection of many of the important statistics required by Oracle Database features and functionality, including:

• Automatic Workload Repository (AWR) Snapshots

• Automatic Database Diagnostic Monitor (ADDM)

• All server-generated alerts

• Automatic SGA Memory Management

• Automatic optimizer statistics collection

• Object level statistics

• End to End Application Tracing (V$CLIENT_STATS)

• Database time distribution statistics (V$SESS_TIME_MODEL and V$SYS_TIME_MODEL)

• Service level statistics

• Buffer cache advisory

• MTTR advisory

• Shared pool sizing advisory

• Segment level statistics

• PGA Target advisory

• Timed statistics

• Monitoring of statistics

二. AWR使用

SQL>@?/rdbms/admin/awrrpt.sql

 

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

 

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 的值: 1

 

Listing the last day's Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

orcl10g ORCL10G 142 03 7月 2009 08:11 1

143 03 7月 2009 09:00 1

144 03 7月 2009 10:00 1

145 03 7月 2009 11:00 1

146 03 7月 2009 12:01 1

 

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

输入 begin_snap 的值: 142

Begin Snapshot Id specified: 142

输入 end_snap 的值: 146

End Snapshot Id specified: 146

 

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_142_146.html. To use this name,

press <return> to continue, otherwise enter an alternative.

输入 report_name 的值: D:/awrrpt_1_142_146.html

 

Report written to D:/awrrpt_1_142_146.html

 

 

三. AWR 操作

 

3.1. 查看当前的AWR保存策略

 

SQL> col SNAP_INTERVAL format a20

SQL> col RETENTION format a20

SQL> select * from dba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION TOPNSQL

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

262089084 +00000 01:00:00.0 +00007 00:00:00.0 DEFAULT

以上结果表示,每小时产生一个SNAPSHOT，保留7天。

 

3.2. 调整AWR配置

 

AWR配置都是通过dbms_workload_repository包进行配置。

 

3.2.1 调整AWR产生snapshot的频率和保留策略，如将收集间隔时间改为30 分钟一次。并且保留5天时间（单位都是分钟）：

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);

 

3.2.2 关闭AWR，把interval设为0则关闭自动捕捉快照

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>0);

 

3.2.3 手工创建一个快照

SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

 

3.2.4 查看快照

SQL> select * from sys.wrh$_active_session_history

 

3.2.5 手工删除指定范围的快照

SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 973, high_snap_id => 999, dbid => 262089084);

 

3.2.6 创建baseline，保存这些数据用于将来分析和比较

SQL> exec dbms_workload_repository.create_baseline(start_snap_id => 1003, end_snap_id => 1013, 'apply_interest_1');

 

3.2.7 删除baseline

SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'apply_interest_1', cascade => FALSE);

 

3.2.8 将AWR数据导出并迁移到其它数据库以便于以后分析

SQL> exec DBMS_SWRF_INTERNAL.AWR_EXTRACT(dmpfile => 'awr_data.dmp', mpdir => 'DIR_BDUMP', bid => 1003, eid => 1013);

 

3.2.9 迁移AWR数据文件到其他数据库

SQL> exec DBMS_SWRF_INTERNAL.AWR_LOAD(SCHNAME => 'AWR_TEST', dmpfile => 'awr_data.dmp', dmpdir => 'DIR_BDUMP');

把AWR数据转移到SYS模式中：

SQL> exec DBMS_SWRF_INTERNAL.MOVE_TO_AWR (SCHNAME => 'TEST');

 

 

四. AWR 报告分析

 

这部分内容，可以参考statspack，这2个内容都差不多。

statspack安装使用和 report 分析

http://andyniu.iteye.com/admin/blogs/1766910

 

 

4.1 SQL ordered by Elapsed Time

记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。

 

Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。

Executions: SQL语句在监控范围内的执行次数总计。

Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。

SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。

SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

SQL Text: 简单的sql提示，详细的需要点击SQL ID。

 

4.2 SQL ordered by CPU Time:

记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

 

4.3 SQL ordered by Gets:

记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。

 

4.4 SQL ordered by Reads:

记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

 

4.5 SQL ordered by Executions:

记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

 

4.6 SQL ordered by Parse Calls:

记录了SQL的软解析次数的TOP SQL。说到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。

 

4.7 SQL ordered by Sharable Memory:

记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。

 

4.8 SQL ordered by Version Count:

记录了SQL的打开子游标的TOP SQL。

 

4.9 SQL ordered by Cluster Wait Time:

记录了集群的等待时间的TOP SQL

 

基线(Baselines)

基线包含了一个特定时间范围的性能数据，用来在性能问题发生时，与其他类似的时间段进行比较。基线中的快照会被自动AWR清除进程排除，并无限期保留。

oracle数据库中包含了三种类型的基线：

固定基线(Fixed Baselines)

固定基线相当于被指定的过去的一个固定的、连续的时间范围。在创建固定基线以前，要慎重考虑这个时间段，因为基线代表了一个理想状态的系统状态。之后，你可以用这个基线和其他基线或者某个时间范围内的快照来分析性能上的退化情况。

移动窗口基线(Moving Window Baseline)

移动窗口基线相当于AWR保留期间内存在的所有AWR数据。在使用自适应阈值时，这将很有用处，因为数据库可以使用AWR保留期间的所有AWR数据来计算出度量阈值。oracle数据库自动维护一个系统定义的移动窗口基线。系统定义的移动窗口基线的默认窗口大小等于当前AWR保留的时间，默认为8天。如果你要使用自适应阈值，可以考虑使用更大的移动窗口，例如30天，可以更精确地计算出阈值。你可以改变移动窗口的大小，这个值要等于或小于AWR保留天数。因此若你需要增大移动窗口的大小，首先需要增加AWR的保留时间。

基线模板(Baseline Templates)

你可以创建一个基线，作为未来一个时间连续的时间段可以使用的基线模板。有两种类型的基线模板：单一的和重复的。你可以为未来一个单独的连续时间段的基线创建单一基线模板。如果你要提前准备获取一个未来的时间段，这个技术会很有用处。例如，你安排好要在周末进行一个系统测试，并准备获取AWR数据，这种情况下，你可以创建一个单一基线模板，用以在测试时自动获取该时间范围内的数据。你也可以使用重复基线模板来创建或者删除一个重复的时间计划，当你想自动获取一个连续的时间范围，这将很有用。例如，你可能希望在一个月里的每周一早晨获取AWR数据，这种情况下，你可以创建一个重复基线模板来自动为每个周一创建基线，并且在设置了过期时间(例如一个月)后，自动删除过期的基线。

自适应阈值(Adaptive Thresholds)

自适应阈值可以帮你以最低的开销监控和检测出性能问题。自适应阈值能够从在移动窗口基线捕获到的度量值里得到的统计信息中，为系统度量自动设置警告和关键报警(warning and critical alert)的阈值。这些统计信息每周会重新生成，并可能由于系统性能随着时间变化改变，而产生新的阈值。

打个比方，很多数据库白天是一个OLTP系统，而到晚上需要执行一些批量进程(例如生成报表)。每个事务响应时间的性能度量对检测OLTP的性能退化问题在白天可能很有用，但是这个阈值常常对于批量工作来说会太低，而频繁触发报警。自适应阈值能检测到这样的工作量模式，并自动为白天和夜里设置不同的阈值。

自适应阈值的类型有两种：

最大值的百分比：阈值以最大值的百分比倍数的方式来计，

重要性级别：阈值被设为一个统计学中的百分位来观察基于移动窗口基线数据的阈值以上的值，来体现异常程度。百分位能指定为以下几种：高(0.95)，100个中只有5个能超过这个值；非常高(0.99)：100个中只有1个能超过这个值；严重的(0.999)：1000个钟只有1个能超过这个值；极端的(0.9999)：10000个钟只有1个能超过这个值。

当一个系统以高峰期工作量来设计的，并且你希望在当前工作量接近或超过先前的高值时触发报警，最大值百分比阈值将非常有用。例如，每秒产生redo量的度量就是个典型的例子。

重要性级别阈值在以下情况很有用：当系统运行正常时表现得很稳定，但当性能变差时可能会在一个大范围内波动。例如，每个事务的响应时间的度量在一个优化过的OLTP系统上将表现平稳，但当性能问题凸显时，可能会波动很大。采用重要性级别阈值，当环境产生不正常的度量值和系统性能时触发报警。

空间消耗(Space Consumption)

以下因素可以被用来判断AWR的空间消耗：在任一给定时间系统中的活动会话数；快照时间间隔，时间间隔越小，快照产生越频繁，增加AWR采集的数据的占用空间；历史数据保留时间

默认情况下，快照每小时捕获一次，并在数据库中保存8天。使用这些默认设置，一个典型的并发量为10个会话数的系统大约需要200-300M的空间来存放AWR数据。但是在降低保留时间的时间，请注意，若AWR中的数据不足，可能会影响一些组件和功能的准确性和精确度：ADDM、SQL Tuning Advisor、Undo Advisor、Segment Advisor。

可能的话，Oracle建议将AWR保留时间设得足够来，至少能捕获一个完整的工作量周期。当你的系统工作量周期为1周，比如工作日是OLTP的工作负荷，而在周末运行批量工作，则默认的8天保留时间不需要去修改。当如果你的系统的高峰期在每个月的月末，那么你可能需要将这个保留时间更改到1个月。

例外情况下，你可以将快照时间间隔改成0来关闭自动收集快照。在这种情况下，工作量和统计数据的自动收集将被停止，且许多Oracle数据库的自动管理功能将不能使用。另外，你不能手动创建快照，因此Oracle强烈建议不要关闭snapshot的自动收集。