性能诊断工具AWR配置策略与报告内容解析

AWR（Automatic Workload Repository）是 Oracle 数据库中的一个重要性能诊断工具。AWR 会按照固定的时间间隔自动收集数据库系统的性能统计信息。这些信息涵盖了数据库运行状态的方方面面，像SQL 执行情况、系统资源利用率、等待事件等。AWR抓取的是一段周期内的综合数据，并非即时的零散样本，这种机制保证数据能反映数据库在实际生产负载下的真实表现。

AWR 数据存储在数据库内部的特定表空间当中，主要由 SYSAUX 表空间承载。保存着不同时间点的性能快照，这些快照如同一张张照片，定格了对应时刻数据库各类性能指标的状态，为后续对比、追溯问题根源提供基础。每个快照都带有详细的时间戳标识，方便使用者精准定位到特定时段的数据库运行情况。

一、AWR配置策略

 1. 调整AWR产生snapshot的频率和保留策略

 AWR配置都是通过dbms_workload_repository包进行配置，如将收集间隔时间改为30 分钟一次，并且保留31天时间（单位都是分钟）：

 SQL> exec 

dbms_workload_repository.modify_snapshot_settings

(interval=>30, retention=>31*24*60);

2. 关闭AWR:

把interval设为0则关闭自动捕捉快照:

SQL> exec 

dbms_workload_repository.modify_snapshot_settings(interval=>0);

3. 手工创建一个快照:

SQL> exec 

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

如果数据库的某些参数或应用程序做了调整，可以手工即时的

创建一个快照更有利于数据的统计分析。

4. 查看快照：

SQL> select * from sys.wrh$_active_session_history

5. 手工删除指定范围的快照

SQL> exec 

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE

(low_snap_id => 2889, high_snap_id => 3000, dbid => 2774909533);

6. 生成awr报告：

awrrpt.sql ：生成指定快照区间的统计报表；

awrrpti.sql ：生成指定数据库实例，并且指定快照区间的统计报表；

awrsqlrpt.sql ：生成指定快照区间，指定SQL语句(实际指定的是该语句的SQLID)的统计报表；

awrsqrpi.sql ：生成指定数据库实例，指定快照区间的指定SQL语句的统计报表；

awrddrpt.sql ：指定两个不同的时间周期，生成这两个周期的统计对比报表；

awrddrpi.sql ：指定数据库实例，并指定两个的不同时间周期，生成这两个周期的统计对比报表；

二、AWR报告的主要内容：

1.前言部分：

这是AWR报告的第一段，用于描述环境包括数据库名，DBID,数据库版本，是否为RAC节点，快照报告的采集时间等。

2. 综述部分：

包含等待事件段，Load Profile段，实例效率统计段，Shared Pool统计段，Cache Size段，其中最重要的是等待事件段，它告诉我们在快照时间内数据库遇到哪些性能瓶颈，它们将是性能调整或问题诊断的主要候选对象。

常见等待事件介绍： 

1）db file sequential read 文件顺序读取 

这一事件通常显示与单个数据块相关的读取操作(如索引读取)。如果 这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题 ，可能没有正确的使用驱动表;或者可能说明不加选择地进行索引。 

在大多数情况下我们说，通过索引可以更为快速的获取记录，所以对 于一个编码规范、调整良好的数据库，这个等待很大是很正常的。但是在 很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据 ，全表扫描可能会明显快于索引扫描，所以在开发中我们就应该注意，对于这样的查询应该进行避免使用索引扫描。

２） db file scattered read-DB 文件分散读取

这种情况通常显示与全表扫描相关的等待。当数据库进行全表扫时，基于性能的考虑，数据会分散(scattered)读入Buffer Cache。如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或者没有创建合适的索引，我们可能需要检查这些数据表已确定是否进行了正确的设置。然而这个等待事件不一定意味着性能低下，在某些条件下Oracle 会主动使用全表扫描来替换索引扫描以提高性能，这和访问的数据量有关，在CBO 下Oracle 会进行更为智能的选择，在RBO 下Oracle 更倾向于使用索引。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物，可能很多是全表扫描操作(不管怎样，这部分信息都是值得我们注意的)。

例：

关于10月21号BOSS全省营业系统故障的处理及分析报告中：

数据库出现 enq: TX - allocate ITL entry 等待事件，某些SQL出现堵塞等待的现象。经确认，该异常为应用程序引发。可能是由于突然有大批量数据导入导致出现ITL的WAITS。该异常直接导致CRM程序出现异常。

３）SQL部分：

无效的SQL语句是性能不好的主要原因，这部分对这段时间区间内SQL按照执行时间，逻辑读，磁盘读等指标进行了分类和排序，和STATSPACK不同的是，从AWR报告中可以直接查到该SQL的文本和发送请求的客户端进程信息，极大的提高了SQL分析的效率。

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 Text: 简单的sql提示，详细的需要点击SQL ID。

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

SQL ordered by Gets: 记录了执行占总buffer gets(逻辑IO)的TOP 

SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。

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

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

SQL ordered by Parse Calls: 记录了SQL的软解析次数的TOP SQL。

点击sql id可以看到具体的sql语句的内容，可以放到查看其具体的执行计划，分析语句的索引使用情况及cost的高低，以便调优sql语句。

4）段统计部分：

告诉哪些段(包括表和索引)在快照期间经历最高的磁盘读操作，这些信息可以帮助我们决定是否需要重建索引，或对段进行分区来减少发生在这些数据文件上的I/O。

 5）收集AWR报告的级别：

AWR的行为受到初始化参数STATISTICS_LEVEL的影响。这个参数有三个值：

BASIC：awr统计的计算和衍生值关闭.只收集少量的数据库统计信息.

TYPICAL：（默认值）只有部分的统计收集.他们代表需要的典型监控oracle数据库的行为. 

ALL : 所有可能的统计都被捕捉. 并且有操作系统的一些信息.这个级别的捕捉应该在很少的情况下,比如你要更多的sql诊断信息的时候才使用。

SQL> show parameter statistics_level

NAME TYPE VALUE

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

statistics_level string TYPICAL

6）基线介绍:

基线（baseline）是一种机制,可以在重要时间的快照信息集做标记。一个基线定义在一对快照之间,快照通过他们的快照序列号识别.每个基线有且只有一对快照。一次典型的性能调整实践从采集量度的基线集合、作出改动、然后采集另一个基线集合开始，可以比较这两个集合来检查所作的改动的效果。在 AWR 中，对现有的已采集的快照可以执行相同类型的比较。

Baseline记录了baseline所指定的快照ID,当维护awr的mmon进程在清除过期的快照时,在baseline中的快照则不会被删除,当数据库做了一段时间的调优后,awr可以用baseline保留的快照与当前系统的awr报告进行对比。