📚 课程目录第4章 AWR、ASH与ADDM实战

4. AWR、ASH与ADDM实战

在Oracle Cloud（OCI）上运行的数据库，性能问题往往不是“数据库慢”这么简单，而是某个具体环节在特定时间段内出现了资源争用。AWR、ASH与ADDM正是Oracle提供的三件套诊断工具：AWR负责保存历史性能快照，ASH负责记录活动会话的实时采样，ADDM则基于AWR数据自动给出瓶颈判断与优化建议。理解三者的分工与配合方式，是定位OCI数据库性能瓶颈的基础。

三件套的分工与数据关系

AWR（Automatic Workload Repository）以固定间隔（默认60分钟）采集一次性能快照，保存等待事件、SQL统计、系统资源使用等累计值。ASH（Active Session History）则每秒采样一次活动会话，记录会话在等待什么、消耗多少CPU。ADDM（Automatic Database Diagnostic Monitor）在每次AWR快照生成后自动运行，分析两个快照之间的差异，输出按影响程度排序的发现项。三者的关系可以用下面的信号链来理解：ASH是细粒度的原始采样，AWR是聚合后的历史快照，ADDM是基于AWR的自动诊断结论。

从ASH开始：秒级定位瞬时尖峰

当业务反馈“刚才数据库卡了几分钟”时，AWR的小时级快照可能已经平滑掉了尖峰。此时应优先查询ASH。在OCI的SQL Developer或SQLcl中连接数据库后，可以执行如下查询，查看最近一段时间内等待事件排名：

SELECT event, COUNT(*) AS samples
FROM   v$active_session_history
WHERE  sample_time > SYSTIMESTAMP - INTERVAL '10' MINUTE
GROUP  BY event
ORDER  BY samples DESC
FETCH FIRST 10 ROWS ONLY;

如果结果显示“enq: TX - row lock contention”或“log file sync”占据主导，说明瓶颈在锁竞争或日志写入，而非CPU。ASH的价值在于它保留了会话级细节，可以进一步下钻到具体SQL_ID和阻塞会话。例如，通过blocking_session字段可以追踪阻塞链，找到源头会话。

AWR报告：小时级趋势与对比分析

ASH适合定位瞬时问题，而AWR适合分析“过去一周每天下午3点都变慢”这类趋势性问题。在OCI控制台或SQLcl中执行@?/rdbms/admin/awrrpt.sql，选择两个快照ID，即可生成HTML或文本格式的AWR报告。报告中需要重点关注的几个部分：

Top 10 Foreground Events by Total Wait Time：按总等待时间排序，快速识别主要瓶颈类型。
SQL ordered by Elapsed Time：找出消耗时间最多的SQL，注意区分单次执行慢和总执行次数多。
Instance Efficiency Percentages：Buffer Hit%、Library Hit%等指标，判断是否存在硬解析或缓存命中率下降。
Wait Classes by Total Wait Time：将等待事件归类为User I/O、Concurrency、Commit等大类，便于判断资源争用方向。

在OCI环境中，AWR快照默认保留8天，可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS调整保留时间和采集间隔。如果数据库负载较高，建议将采集间隔从60分钟缩短到30分钟，以便更精细地捕捉变化。

ADDM：自动诊断与优先级排序

ADDM在每次AWR快照生成后自动运行，分析两个快照之间的性能数据，输出发现项（Finding）和建议（Recommendation）。执行@?/rdbms/admin/addmrpt.sql可以生成ADDM报告。ADDM报告的核心价值在于它按“影响百分比”排序，直接告诉DBA哪个问题最值得优先处理。

例如，ADDM可能输出：“Top SQL statements”影响占比45%，建议检查特定SQL的执行计划；“I/O throughput”影响占比20%，建议检查存储层带宽。在OCI中，ADDM的发现项还可以与OCI监控服务（Monitoring）的指标联动，比如当ADDM指出I/O瓶颈时，可以同步查看块存储的吞吐量和IOPS是否达到上限。

ADDM报告中的“Impact”百分比是相对于整个数据库时间的占比，不是相对于问题时段。因此，如果问题时段只占一天中的一小部分，ADDM的影响百分比可能看起来不高，但仍需结合AWR报告中的具体时段数据来判断。

实战组合：一次完整的瓶颈定位过程

假设OCI上某数据库在每天上午10:00-10:30出现响应变慢。按照以下顺序操作：

用ASH查询10:00-10:30的等待事件分布，发现“db file sequential read”占比最高，说明存在大量单块读。
生成该时段的AWR报告，查看“SQL ordered by Physical Reads”，找到物理读最高的SQL_ID。
查看该SQL的执行计划，确认是否走了全表扫描或索引选择率不佳。
生成ADDM报告，确认ADDM是否也识别出该SQL为高影响项，并查看其建议（如“考虑创建索引”或“收集统计信息”）。
在OCI控制台检查该时段块存储的IOPS和吞吐量，排除存储层瓶颈。

通过ASH→AWR→ADDM的递进式分析，可以将“数据库慢”这个模糊问题，收敛到具体的SQL、等待事件和资源类型。在OCI环境中，还可以结合Autonomous Database的自动索引和SQL调优建议，进一步缩短从诊断到修复的路径。

AWR和ADDM依赖STATISTICS_LEVEL参数为TYPICAL或ALL。如果该参数被设置为BASIC，AWR快照和ADDM分析将无法正常工作。在OCI的DB系统上，默认值为TYPICAL，但迁移或手动修改后需确认该参数。

最后需要强调的是，AWR、ASH和ADDM是诊断工具而非调优工具。它们告诉你“哪里慢、为什么慢”，但具体的修复动作——比如添加索引、重写SQL、调整内存参数——仍需结合业务逻辑和OCI资源规格来决策。在OCI上，还可以利用Performance Hub的图形化界面，将ASH、AWR和ADDM的数据整合在同一时间轴上查看，进一步降低诊断门槛。