想要弄清楚AWR的价值，先得理解它到底在记录什么。简单来说，AWR是Oracle数据库内部的一个长期统计信息仓库，它周期性采集与数据库负载相关的各类活动数据，并把这些数据以快照的形式持久化保存。这些数据并非零散的日志，而是经过整合的累积指标和增量指标，覆盖了内存使用、等待事件、SQL执行情况、系统级统计、I/O读写等多个维度。通过对两个不同时间点的快照做差值计算，AWR报告能够还原出这段时间内数据库到底把时间耗费在了哪些环节上。
从定位问题的角度看，AWR最大的意义在于提供了时间维度上的横向对比能力。比如某天凌晨出现了批处理任务变慢的情况，如果当时没有实时监控，事后依然可以通过AWR找到对应的快照区间，观察那时候的等待事件排名和负载曲线。相比Statspack，AWR不需要DBA手动设置作业，它在数据库创建后默认启用，由后台进程MMON自动完成采集和清理动作，运维成本明显更低。
还需要明确一点，AWR并不是一个单纯的性能日志，它是一套完整的工作负载分析框架。除了最常用的文本报告，Oracle还将AWR数据作为自动数据库诊断监视器ADDM、SQL调优建议等功能的输入来源。也就是说，AWR采集的原始数据既可以直接生成报告供人工阅读，也可以被其他工具进一步加工分析，这使得它在Oracle 10g之后的诊断体系中处于核心位置。
AWR的核心组件与数据采集机制
AWR由几个关键部分组成，包括内存中的性能统计信息、落盘的历史快照、生成报告所需的SQL脚本以及负责自动维护的后台任务。其中最重要的概念就是快照。快照本质上是对特定时间点数据库统计信息的完整拷贝，默认情况下Oracle每隔60分钟生成一次，并且通过DBMS_WORKLOAD_REPOSITORY包可以调整间隔和保留时长。
在采集过程中，Oracle并不是把所有V$动态性能视图的内容都原封不动存下来。AWR会针对那些具有累计性质或反映系统状态的指标进行筛选和加工。例如等待事件的总等待次数、总等待时间、执行过的SQL的CPU时间、逻辑读、磁盘读、行处理数量等，这些数据大多以累计值形式保存。计算区间指标时，需要用后一个快照的累计值减去前一个快照的累计值，再除以区间时长，得到每秒的负载情况。这种设计避免了长期存储原始活动数据带来的空间膨胀问题。
自动采集由MMON进程触发，MMON会定期唤醒并检查是否需要生成快照，同时负责将内存中的统计信息刷入AWR底层的基表。AWR基表存储在SYSAUX表空间里，这也就解释了为什么Oracle 10g中SYSAUX表空间的默认大小会比原来的系统辅助表空间大很多。快照的保留策略默认是7天，用户可以根据实际需求通过如下PL/SQL代码调整快照间隔和保留时间：
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
retention => 43200, -- 保留30天，单位：分钟
interval => 30, -- 每30分钟采集一次
topnsql => 100 -- 每个维度保留Top 100的SQL
);
END;
/
如果希望手动立刻创建一个快照，可以使用CREATE_SNAPSHOT过程。手动快照在应用发布或压力测试前非常有用，能够在时间轴上标记出一个明确的分界点。创建完成后，通过DBA_HIST_SNAPSHOT视图可以查看当前已经存在的快照编号和采集时间。
-- 手动创建AWR快照 EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT; -- 查询最近10次快照信息 SELECT snap_id, begin_interval_time, end_interval_time FROM ( SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC ) WHERE ROWNUM <= 10;
值得注意的是，AWR采集的快照并不是只有数据库空闲时才进行。哪怕系统正在经历极高负载，MMON依然会尽量完成快照生成，只是可能出现轻微延迟。此外，AWR的采集精度也受统计信息级别的影响。初始化参数STATISTICS_LEVEL必须设为TYPICAL或ALL，AWR才会正常自动采集。如果该参数被改成BASIC，很多AWR功能都会失效，这也是排查AWR无数据时首先要检查的设置。
如何生成并阅读AWR报告
生成AWR报告最常用的方式是在数据库服务器上执行awrrpt.sql脚本，该脚本通常位于ORACLE_HOME/rdbms/admin目录下。执行后会提示选择输出格式、输入起始快照ID和结束快照ID，最后生成一份HTML或文本格式的报告。对于RAC环境，则有专门的awrgrpt.sql用于生成整集群级别的报告。
报告中最先需要关注的是Summary部分。这里会列出快照区间内数据库的DB Time、CPU Time、用户调用次数、事务数等基本指标，同时也会给出Elapsed Time和DB Time的对比。DB Time是数据库处理用户请求所消耗的总CPU时间和非空闲等待时间之和，如果DB Time远大于Elapsed Time乘以CPU核数，说明系统存在较为严重的等待竞争。例如一个8核数据库在10分钟内DB Time达到400分钟，平均活跃会话数就是40，这意味着有大量会话在排队等待资源。
Load Profile部分显示每秒和每事务的资源消耗指标，比如每秒逻辑读、每秒物理读、每秒执行SQL数、每秒登录次数等。通过与历史正常时段的报告对比，可以判断当前负载是否偏离常态。随后是Instance Efficiency Percentages，也就是多种命中率指标。虽然命中率在性能分析中的重要性已经不像早期那样被绝对化，但Buffer Hit Ratio过低仍然可能是I/O压力的信号。
Top等待事件是AWR报告中最直接的诊断线索。按照总等待时间降序排列，每个等待事件都包含等待次数、总等待时间和平均等待时间。如果排在前面的都是CPU Time或正常的I/O等待，通常说明系统没有明显的瓶颈点。一旦发现诸如enq: TX - row lock contention、log file sync、db file sequential read等事件的等待占比异常高，就应该结合具体的应用操作和SQL语句进一步排查。下面的SQL可以直接查询某类等待事件在快照区间内的变化情况：
SELECT event_name, total_waits, time_waited_micro / 1000000 AS seconds_waited FROM dba_hist_system_event WHERE snap_id BETWEEN :begin_snap AND :end_snap AND event_name LIKE '%log file sync%' ORDER BY time_waited_micro DESC;
SQL Statistics部分负责展示区间内消耗资源最高的SQL语句。按Elapsed Time排序后，通常最靠前的几条SQL就是优化的重点对象。AWR给出了每条SQL的执行次数、每次执行平均耗时、CPU时间、等待时间、逻辑读和物理读等关键指标。需要注意的是，有些SQL虽然逻辑读很高，但执行次数也非常大，平均消耗并不突出，这时要结合业务特点判断是否需要优化。另外，如果某条SQL的版本数很多，可能是因为绑定变量窥探或统计信息变化导致了多个执行计划，需要检查执行计划是否稳定。
AWR与Statspack的差异及使用注意事项
Oracle 9i时代DBA通常依赖Statspack进行性能分析，但它需要手工安装、手工调度采集任务，而且默认只收集有限范围的指标。AWR作为10g的原生组件，在采集深度、自动化程度和与其他诊断工具的集成上有明显优势。AWR收集的数据不仅包括Statspack原有的等待事件和系统统计，还扩充了时间模型、活动会话历史、段级统计、操作系统统计等丰富信息。
另一个关键差异是资源开销。Statspack在采集瞬间会执行大量查询来抓取V$视图数据，如果采集频率过高，本身就可能对生产系统造成一定压力。AWR的采集由Oracle内部机制完成，通过与自动内存管理、自动优化器统计信息收集等模块协同工作，降低了采集动作对前台业务的干扰。即便如此，在超大规模系统上，AWR的快照生成仍然会消耗一些CPU和I/O资源，因此不建议把间隔设置得过于激进，比如少于10分钟一次。
在使用AWR时，有几点需要特别注意。首先，快照默认只保留7天，如果做月度性能回顾，应该提前调大保留时间。其次，AWR报告展示的是区间内的平均情况，无法还原每一个瞬间的波动细节。如果问题是间歇性的短时尖刺，光看60分钟间隔的AWR报告可能发现不了问题，这时需要借助ASH，也就是活动会话历史，进行更细粒度的分析。再次，AWR数据存储在SYSAUX表空间中，如果快照保留策略过久或者系统SQL数量庞大，SYSAUX可能会膨胀，需要定期检查空间占用情况。
最后，要正确理解AWR报告中的指标含义，避免陷入过度优化单项指标的错误路径。比如单纯为了把Buffer Hit Ratio从95%提高到99%而大幅增加缓存，未必能带来业务上的实际改善。更好的做法是从DB Time、Top等待事件和Top SQL三个维度出发，先找到真正影响用户体验的环节，再结合AWR提供的具体证据制定优化方案。
Oracle AWR自动工作负载仓库性能诊断修改时间：2026-08-25 19:43:11