awr对比报告必须配对分析正常与问题时段两份时长一致的报告，单份报告无法识别异常；需重点对比top 5 timed events、load profile、sql statistics及instance efficiency percentages中per second和% db time的差值，差异即瓶颈所在。
AWR对比报告不是“多看一份报告”，而是用两份时间长度一致、但负载状态相反的报告做差值分析——问题不在单份报告里，而在差异中。
为什么必须配对看：正常时段 vs 问题时段
单份AWR报告只告诉你“当时发生了什么”，但无法回答“比平时多了什么”。比如db file sequential read等待10万次，你不知道这是常态还是异常；但如果正常时段只有800次，问题时段飙升到10万，就立刻指向索引失效或执行计划突变。
- 两份报告必须时长严格一致（如都是30分钟），否则
Per Second类指标不可比 - 正常时段不能选在深夜或周末——要选同业务类型、同流量级的参照窗口（例如工作日上午10点）
- 避免用备份/维护窗口做参照，这类时段
DB Time可能极低，导致所有指标失真
重点对比这4个位置的数值差
别通读全文，直接定位以下四个模块，逐项拉出Per Second和% DB Time两列做减法：
-
Top 5 Timed Events：重点关注free buffer waits、enq: TX - row lock contention、log file sync等非空闲等待是否成倍增长 -
Load Profile中的Logical reads和Physical reads：若逻辑读翻倍但物理读只涨10%，大概率是执行计划从索引扫描退化为全表扫描 -
SQL Statistics里Executions和Buffer Gets/Exec：某条SQL执行次数不变，但每次逻辑读暴涨，说明它内部访问路径变差 -
Instance Efficiency Percentages中的Buffer Hit Ratio：从97%掉到89%，结合free buffer waits上升，基本锁定Buffer Cache压力过大
DB Time比值失真时怎么判断真实负载
当DB Time / (Elapsed × CPU_COUNT)
- 查
Time Model Statistics里的sql execute elapsed time占比：如果它占DB Time超90%，而DB CPU占比却很低，说明SQL在等IO或锁，不是CPU问题 - 看
Average Active Sessions (AAS)绝对值：即使比值 - 注意集群环境：必须用单实例的
CPU_COUNT去除本实例的DB Time，别用总核数
容易被忽略的陷阱：License和采样精度
对比结果不准，常常不是分析错，而是报告本身就不合法。
- 没有
Oracle Diagnostic PackLicense时，AWR报告里Top SQL和ASH相关数据会被阉割，SQL_ID字段为空或显示为0000000000000000 - 默认1小时采样间隔，若卡顿只持续5分钟，这份报告根本抓不到峰值——此时必须用
ASH按秒级下钻，再反向定位对应SNAP_ID -
DBA_HIST_SNAPSHOT保留期默认8天，问题发生在9天前？dba_hist_snapshot里已无记录，得提前配置延长保留策略
真正卡住人的，往往不是看不懂报告，而是没意识到两份报告的时间对齐精度、License限制、采样粒度这些底层约束正在悄悄扭曲你的判断。
