如何利用AWR验证优化成果_对比优化前后同一时间段的性能指标报告

张开发
• 2026/4/15 2:29:46 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

如何利用AWR验证优化成果_对比优化前后同一时间段的性能指标报告
选对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 倍这往往意味着缓冲区被挤出大量逻辑读转成了物理读——表面快了实则把压力甩给了存储。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。

更多文章