直接对比AWR报告而不验证基线真实性是常见错误；基线是带语义的性能锚点，需查DBA_HIST_BASELINE确认类型，生成对比报告时须显式指定baseline_name，避免误用普通快照。

怎么看基线和当前AWR报告的差异

直接对比两个awr报告，不看基线定义就下结论，是90%人踩的第一个坑。oracle里“基线”不是快照集合，而是带语义的性能锚点——它告诉awr：“这组快照代表‘健康态’，后续所有对比都以它为尺子”。所以第一步永远不是打开报告，而是确认你用的真是基线，而不是随手选的两段普通时间。

• DBA_HIST_BASELINE 里查 baseline_name 和 baseline_type（STATIC 或 MOVING_WINDOW），别只信名字里带“baseline”的；
• 用 @?/rdbms/admin/awrddrpt 生成对比报告时，必须显式指定 baseline_name，不能只输起止快照ID——否则它默认比的是普通快照，根本没走基线逻辑；
• 基线窗口太窄（比如只包1个快照）或跨了维护窗口（如统计信息收集、备份任务），会导致基线本身失真，比出来全是假阳性。

DB Time 和 AAS 这两个数怎么读才不误导

DB Time 高 ≠ 系统慢，AAS 高 ≠ 一定出问题。它们只是负载密度指标，必须结合时间粒度和业务上下文看。比如某天 AAS=8，看着高，但如果那是促销峰值且持续仅15分钟，就合理；而如果连续4小时 AAS=2.5 却伴随大量超时，那才是退化信号。

• AAS = DB Time / Elapsed Time，分母是真实流逝时间，不是数据库运行时间——所以对比时务必确保两个时间段的 Elapsed Time 接近（比如都取1小时），否则数值不可比；
• 查历史趋势别只看单点值，用官方SQL跑7天滚动 DB Time：里面 per_sec 字段才是单位时间压力，比绝对值更有意义；
• 如果基线期 AAS=1.2，当前期 AAS=1.8，但 DB Time 增幅只有15%，说明负载变重但效率没崩——可能只是并发用户多了，未必是SQL或IO问题。

等待事件对比时，盯死“归一化后的时间占比”

直接比“log file sync 等待次数”从1000涨到5000，没意义。要看它占总等待时间的比例是否异常跃升。因为总等待时间本身可能因负载变化而浮动，只看次数会把正常增长误判成故障。

• 在AWR报告的 Wait Events 表格里，重点看 % DB Time 列，不是 Total Waits；
• 基线期 buffer busy waits 占比0.3%，当前期跳到4.2%，且集中在某个表空间——立刻查该表空间对应的数据文件I/O延迟（iostat -x 1 或 V$FILESTAT）；
• 如果多个等待事件占比同步上升（比如 latch: cache buffers chains 和 read by other session 都翻倍），大概率是热块争用，不是IO瓶颈，别急着加磁盘。

SQL执行计划变更怎么快速定位

AWR里SQL统计只告诉你“这SQL变慢了”，但不会说“为什么变慢”。真正要抓退化根因，得把基线期和当前期的 SQL_ID 对应的执行计划拉出来人工比对——尤其关注访问路径、连接方式、预估行数这三处。

• 用 DBMS_XPLAN.DISPLAY_AWR('<code>SQL_ID', baseline_snap_id) 和 DISPLAY_AWR('<code>SQL_ID', current_snap_id) 分别抽计划，别依赖报告里模糊的“Plan Hash Value”；
• 常见退化模式：INDEX RANGE SCAN 变成 FULL TABLE SCAN（索引失效）、NESTED LOOPS 变成 HASH JOIN（驱动表估算错误）、Cardinality 预估从100变成10000（统计信息陈旧）；
• 如果计划没变但执行时间翻倍，直接跳过SQL优化环节，回头查资源争用——大概率是CPU或内存被其他进程挤占了。

基线不是万能标尺，它只反映你当初定义它时的系统状态。如果基线建在未收集统计信息的库上，或者建在RAC某节点独占流量的时段，那它本身就是错的刻度。比数据前，先花两分钟确认基线本身的可信度，比花两小时调SQL更省力。