性能排查的第一道门槛不是会不会优化而是会不会读报告。AWR 是全景地图ASH 是放大镜ADDM 是自动参谋。本篇按接手报告 → 30 分钟完成定位的顺序给出每个阶段的读法和红线阈值。一、三板斧的分工工具本质粒度什么时候用AWR快照区间内的性能数据聚合报告默认 30 分钟一个快照系统级整体变慢看趋势ASH活动会话的每秒采样秒级AWR 定位方向后抓具体会话/SQLADDM基于 AWR 快照对的自动诊断快照区间要官方建议快速初判口诀看 DB Time 估负载看 Top Event 找方向看 Top SQL 找真凶看 IO 找瓶颈ASH 修精度ADDM 给建议Diff 证结论。二、阶段 1接手准备2 分钟确认快照区间覆盖故障时刻——离谱但常见拿着昨天下午的报告分析今天早上的故障区间长度 30 分钟~4 小时过短被尖刺带偏过长被平均抹平区间缺失就先补快照再生成报告EXECDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;$ORACLE_HOME/rdbms/admin/awrrpt.sql-- 交互式选区间出 HTML/文本报告$ORACLE_HOME/rdbms/admin/ashrpt.sql-- ASH 报告$ORACLE_HOME/rdbms/admin/addmrpt.sql-- ADDM 报告$ORACLE_HOME/rdbms/admin/awrddrpt.sql-- AWR Diff故障时段 vs 正常时段三、阶段 2通览全局3 分钟3.1 报告头先看 DB TimeDB Time 所有会话花在数据库里的时间总和CPU 非空闲等待读数结论DB Time Elapsed × CPU 核数高负载值得深挖DB Time ≈ Elapsed系统基本空闲慢多半在别处网络/应用3.2 Load Profile负载画像指标关注点Redo size / sec突然飙升 → 大批量写入/批量 DMLLogical reads / sec持续 10 万/秒通常有优化空间Physical reads / sec 5000 警告 10000 严重Executions / Transactions突增 → 应用侧出问题重试风暴/循环调用3.3 Instance Efficiency命中率体检命中率红线异常含义Buffer Hit≥ 95%低 → 全表扫描太多 / SGA 偏小SQL Cache Hit软解析比≥ 90%低 → 字面量 SQL / 共享池问题In-Memory Sort≥ 95%低 → PGA 太小或大排序Redo NoWait≥ 99%低 → redo log 太小频繁切换提醒命中率是体检指标不是目标。90% 命中率的三千万次逻辑读比 99% 的三百万次更值得优化——绝对量永远优先于比率。四、阶段 3定位瓶颈核心 15 分钟4.1 Top 5/10 等待事件——AWR 的灵魂把 Top 等待按类别归类直接指向根因方向等待事件指向db file scattered read全表扫描/多块读 → SQL 缺索引db file sequential read索引回表/单块读密集 → IO 抖动或索引选择差log file sync提交慢 → 详见 [[08-log-file-sync提交慢专题]]enq: TX - row lock contention行锁争用 → [[09-锁阻塞与死锁排查]]enq: TM - contention表锁DDL 撞 DML、外键无索引buffer busy waits块热点/段头争用latch: shared pool/cursor: mutex X硬解析过多/游标共享问题CPU time主导SQL 计算密集 / 硬解压严重 / CPU 真不够gc buffer busy *RAC跨节点块争用 → 私网或应用亲和性判断标准单一事件占 DB Time 30% 值得处理 50% 是主要矛盾。4.2 Top SQL必须与等待事件交叉验证不同等待主导看不同排序的 SQL 段等待主导优先看IO 类等待SQL ordered by Physical ReadsCPU 主导SQL ordered by CPU Time整体慢SQL ordered by Elapsed Time高频小事务SQL ordered by Executions锁定 SQL_ID 后取执行计划SELECT*FROMTABLE(DBMS_XPLAN.DISPLAY_AWR(sql_id));4.3 表空间 IO 段平均读延迟 10ms → 存储层瓶颈或顺序/随机读模式问题单个表空间占全库 IO 60% → 热点考虑打散数据文件/分区。五、阶段 4验证回溯5 分钟AWR 是区间平均会掩盖只有 12:00–12:05 慢这类瞬时问题。三个补精度工具-- ① ASH直接查故障分钟的活动会话数据库层SELECTevent,sql_id,COUNT(*)FROMdba_hist_active_sess_historyWHEREsample_timeBETWEENTO_DATE(2026-08-14 12:00,yyyy-mm-dd hh24:mi)ANDTO_DATE(2026-08-14 12:05,yyyy-mm-dd hh24:mi)GROUPBYevent,sql_idORDERBY3DESC;-- ② ADDM要一份官方诊断-- ③ AWR Diff正常时段 vs 故障时段差异项就是嫌疑犯OS 层用 OSWOSWatcher数据交叉验证数据库说 IO 慢OSW 里磁盘 util 也是 100%才能定罪存储。六、阶段 5修复与复盘瓶颈典型方案SQL 慢加索引 / 改写 / 收集统计信息[[10-慢SQL分析路径]]锁争用应用层避免并发冲突、KILL 持锁会话[[09-锁阻塞与死锁排查]]IO 瓶颈扩存储、SQL 降逻辑读、热点表空间打散内存调 SGA/PGA、绑定变量压硬解析redo 切换频繁日志加大到 30 分钟切一次[[08-log-file-sync提交慢专题]]铁律修复后抓一份同时段 AWR 做 Before/After 对比用 DB Time 数字说话不做感觉好多了式结案。七、巡检阈值表可直接配监控指标警告严重Buffer Hit Ratio 95% 90%物理读/秒 5000 10000日志切换/小时 10 20Top 等待事件占 DB Time 30% 50%另AWR 默认只保留 8 天长期基线问题记得提前调MODIFY_SNAPSHOT_SETTINGS(retention43200)30 天。八、小结六阶段流程准备 → 通览 → 定位瓶颈 → 验证回溯 → 方案落地 → 归档复盘DB Time 定性负载Top 等待事件定方向Top SQL 定真凶与 IO 段交叉定罪ASH 修精度、ADDM 给建议、Diff 证结论修复必须有 Before/After 数据。下一篇[[07-等待事件入门与OWI方法]] —— 把等待事件这套语言学会并用一个节点宕机案例走完整流程。