AWR ASH与性能诊断
AWR、ASH 和 ADDM 是 Oracle 性能诊断的重要工具。它们能把时间、等待、SQL、会话、对象和系统指标关联起来，帮助团队从感知慢走向证据链分析。
# 1. 学习目标与定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 高级运维 |
| 核心目标 | 从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来 |
| 适合人群 | 开发人员通过 SQL_ID 和业务时间协助定位；运维人员通过 AWR/ASH 建立性能证据链。 |
# 2. 核心概念总览
AWR ASH与性能诊断
├─ AWR Snapshot
├─ ASH
├─ ADDM
├─ Time Model
├─ Top SQL
├─ Top Wait Events
├─ Instance Efficiency
├─ SQL Report
└─ Baseline
这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。
# 3. 底层原理详解
Oracle 性能诊断以数据库时间为核心。数据库时间由活动会话消耗的 CPU 时间和非空闲等待时间组成。用户觉得慢，要先问数据库时间花在哪里。
AWR 是周期性快照，适合看区间趋势和 Top SQL；ASH 是活动会话采样，适合看某一时间段谁在等待什么；ADDM 基于 AWR 给出自动诊断建议，但建议仍需人工判断。
AWR/ASH 的价值取决于时间窗口。选错时间窗口会把正常高峰、故障尖刺和低峰平均在一起，导致结论完全偏离。
# 4. 关键机制拆解
# 4.1. AWR 快照与时间窗口
AWR 保存实例负载、等待事件、SQL、段统计、系统指标等快照。报告区间应该覆盖问题发生时段，并尽量与正常时段对比。
不要拿全天报告分析一分钟故障。故障尖刺会被平均值稀释，必须缩小窗口或使用 ASH。
# 4.2. ASH 活动会话采样
ASH 以采样方式记录活动会话，包括 SQL_ID、等待事件、对象、会话、模块和阻塞信息。它适合回答“故障那几分钟到底谁在忙”。
应用若设置 module/action/client_identifier，ASH 就能更容易把数据库活动映射回业务场景。
# 4.3. Top SQL 与 Top Wait Events
Top SQL 告诉资源消耗最大的 SQL，Top Wait Events 告诉主要等待类型。两者必须结合：同一 SQL 消耗高可能是 CPU、IO、锁、网络或并行等待。
调优优先级应按数据库时间和业务影响排序，而不是按单次执行最慢排序。
# 4.4. Baseline 与容量趋势
AWR Baseline 能保存正常业务基线，用于对比发布前后、促销前后和参数调整前后。容量规划也需要从 AWR 中提取 CPU、IO、连接数、事务量和 SQL 增长趋势。
没有基线，团队只能凭感觉判断“比以前慢”。有基线，才能说清慢在哪里、慢多少、从什么时候开始。
# 5. 功能模块细节补充
本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。
# 5.1. AWR Snapshot
AWR Snapshot 是性能诊断证据链中的观察点。Oracle 调优要先看数据库时间花在哪里，再关联 SQL_ID、等待事件、对象、会话、系统资源和变更记录；该模块用于把“感觉慢”变成可验证结论。
# 5.2. ASH
ASH 是性能诊断证据链中的观察点。Oracle 调优要先看数据库时间花在哪里，再关联 SQL_ID、等待事件、对象、会话、系统资源和变更记录；该模块用于把“感觉慢”变成可验证结论。
# 5.3. ADDM
ADDM 是性能诊断证据链中的观察点。Oracle 调优要先看数据库时间花在哪里，再关联 SQL_ID、等待事件、对象、会话、系统资源和变更记录；该模块用于把“感觉慢”变成可验证结论。
# 5.4. Time Model
Time Model 是性能诊断证据链中的观察点。Oracle 调优要先看数据库时间花在哪里，再关联 SQL_ID、等待事件、对象、会话、系统资源和变更记录；该模块用于把“感觉慢”变成可验证结论。
# 5.5. Top SQL
Top SQL 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 5.6. Top Wait Events
Top Wait Events 表示并发控制或内部同步资源。它可能保护业务行、表级 DDL/DML 协调、事务资源、内存结构或热点块；排查时要找到等待者、持有者、SQL_ID、对象和事务开始时间。
# 5.7. Instance Efficiency
Instance Efficiency 是实例与数据库协作链路中的组成部分。实例侧负责运行时内存、进程和调度，数据库侧负责控制文件、数据文件和日志文件；该模块的异常通常会反映到启动阶段、后台进程等待、告警日志或恢复流程中。
# 5.8. SQL Report
SQL Report 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 5.9. Baseline
Baseline 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 6. 开发人员重点提醒
- 应用设置 module/action，保留 SQL_ID 和业务请求号。
- 发布前后关注核心 SQL 的耗时和执行次数变化。
- 性能问题反馈要提供准确时间段。
# 7. 运维人员重点提醒
- 生成 AWR 时选择正确问题窗口和对比窗口。
- ASH 用于分析尖刺、阻塞链和短时抖动。
- 建立核心系统性能基线。
# 8. 典型问题与排查
- 平均负载正常但用户慢：用 ASH 看尖刺窗口。
- Top SQL 变了：比较发布、统计信息刷新和计划哈希。
- 等待事件变化：关联存储、网络、锁和后台进程。
# 9. 实践建议与检查清单
- AWR 快照策略明确
- ASH 权限和保留可用
- 核心业务设置 module
- 有正常基线
- 报告结论能关联 SQL 和等待
# 10. 阶段小结
本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。