选对AWR快照时间范围需精确到分钟级对齐起止时间，用DBA_HIST_SNAPSHOT核验BEGIN_INTERVAL_TIME和END_INTERVAL_TIME完全一致，避开跨日切片与过渡态，优先选批处理刚结束的快照。
怎么选对 AWR 快照时间范围做对比
awr 报告对比失效，八成是因为快照时间没对齐。优化前后的报告必须覆盖完全相同的数据库活动周期——不是“差不多同一周”，而是精确到分钟级的起止时间点。
- 用
DBA_HIST_SNAPSHOT查两个时段的SNAP_ID，确认BEGIN_INTERVAL_TIME和END_INTERVAL_TIME完全一致 - 避免跨日切片：比如优化前取 09:00–10:00，优化后却取 08:55–09:55，哪怕只差 5 分钟，
DB Time和Logical Reads就可能因负载波动失真 - 如果业务有固定节奏（如每小时批处理），优先选批处理刚结束的快照，避开中间过渡态
哪些 AWR 指标真能说明优化有效
别盯着 Buffer Hit Ratio 或 Library Hit Ratio 看——这两个值早就不反映真实瓶颈了。重点盯三类指标：
-
DB Time：下降 15% 以上才值得信；如果只降 2%，大概率是采样噪声或后台任务干扰 -
SQL ordered by Elapsed Time列表里，原 TOP 1 SQL 的Elapsed Time Per Exec是否显著降低（注意看单位：ms 还是 s） -
Instance Efficiency Percentages下的Parse CPU to Parse Elapsed %：如果从 30% 升到 95%，说明硬解析大幅减少，cursor_sharing或绑定变量起了作用
为什么用 awrddrpt.sql 而不是手动拼两个 awrrpt.sql
手动生成两份 awrrpt.sql 报告再肉眼比对，容易漏掉隐性变化：比如某 SQL 执行次数翻倍但单次耗时减半，总 DB Time 不变，但系统吞吐其实提升了。
-
awrddrpt.sql是 Oracle 官方提供的差异报告脚本，自动对齐快照、归一化统计口径、高亮 delta 值 - 运行时指定
report_type为html，它会用颜色标出上升/下降超 10% 的项，比扫表格快得多 - 注意传参顺序：
awrddrpt.sql第一个参数是「优化后」快照范围，第二个是「优化前」，反了会导致所有 delta 符号颠倒
常见误判场景：指标变好但实际更糟
优化后 DB Time 降了，Physical Reads 却涨了 3 倍？这往往意味着缓冲区被挤出，大量逻辑读转成了物理读——表面快了，实则把压力甩给了存储。
- 查
Buffer Pool Advisory部分，确认Estimated Physical Reads是否随Buffer Pool Size增加而下降；如果不是，说明当前 buffer cache 已经不够用 - 如果
Shared Pool Free Memory在优化后报告里持续低于 50MB，ORA-04031风险就在眼前，此时Library Cache Hit %的微升毫无意义 - 对比时务必打开
Top 5 Timed Foreground Events：如果从前是db file sequential read，现在变成latch: shared pool，说明优化引入了新争用
事情说清了就结束。AWR 对比不是看数字变小就完事，关键在理解数字背后的数据流动路径和资源置换关系。
