AWR基线是带语义的性能锚点而非快照集合；必须通过DBA_HIST_BASELINE确认baseline_type='STATIC'，并用awrddrpt显式指定baseline_name，否则默认执行普通快照对比，导致假阳性结论。
AWR基线不是快照集合，而是带语义的性能锚点
直接拿两段普通快照比对就下结论，是90%人踩的第一个坑。oracle里“基线”必须显式创建并验证类型，否则awrddrpt默认走的是快照对比逻辑，根本不会触发基线语义。
确认是否真用了基线，必须查DBA_HIST_BASELINE：
SELECT baseline_name, baseline_type, start_snap_id, end_snap_id FROM dba_hist_baseline WHERE baseline_type = 'STATIC';
常见错误包括：
- 误把
create_baseline返回的“成功”当真，没检查baseline_type是否为STATIC（动态基线不参与awrddrpt对比） - 基线窗口只含1个快照，或跨了统计信息收集窗口，导致基线本身失真
- 用
awrrpt.sql生成单报告后手动“ eyeball 对比”，绕过了基线校验机制
用awrddrpt生成基线对比报告时必须显式指定baseline_name
awrddrpt脚本不接受快照ID范围作为基线输入——它只认baseline_name。输错参数会静默 fallback 到普通快照对比，但报告标题里不会提示你“这不是基线对比”。
正确操作流程：
- 连接后执行
@?/rdbms/admin/awrddrpt - 格式选
HTML，时间范围选1（表示1天内） - 当提示
Enter value for baseline_name:时，必须输入DBA_HIST_BASELINE里查到的准确名称，比如PROD_PEAK_HOUR - 若留空或输错，它会回退到快照ID模式，但不会报错，只会生成一份“看起来像基线对比”的假报告
验证是否真走了基线路径：打开生成的HTML报告，搜索Baseline，看“Baseline Details”章节是否列出基线起止快照及类型；若只有“Start Snap ID / End Snap ID”，说明没生效。
基线对比结果里AAS和DB Time增幅不匹配，说明负载变化但效率未崩
比如基线期AAS=1.2，当前期AAS=1.8（+50%），但DB Time只涨了15%，这通常不是故障信号——更可能是并发用户数上升、SQL执行变多，但单条SQL效率没恶化。
此时要避开两个陷阱：
- 别急着优化Top SQL：先看
SQL ordered by Executions，确认是否新增了高频轻量SQL（如心跳查询），而非原有SQL变慢 - 别只盯等待事件次数：结合
Top 5 Timed Events里的“Avg wait ms”列，如果db file sequential read平均等待时间仍低于10ms，IO没变慢，只是读得更勤了 - 检查
System Statistics里的Logons cumulative和Executes cumulative，增幅是否与AAS同比例
多个等待事件同步翻倍，大概率是热块争用而非IO瓶颈
当latch: cache buffers chains、read by other session、buffer busy waits三者在对比报告中占比同时翻倍，基本可排除磁盘IO问题——这是典型的缓冲区热块争用特征。
下一步动作要聚焦内存访问路径：
- 查
SQL ordered by Gets，定位高Buffer Gets的SQL，尤其关注INDEX RANGE SCAN或TABLE ACCESS BY INDEX ROWID类操作 - 用
dba_hist_active_sess_history回溯具体争用对象：SELECT p1text, p1, p2text, p2, current_obj# FROM dba_hist_active_sess_history WHERE event = 'latch: cache buffers chains' AND sample_time BETWEEN ... AND ...;
- 避免盲目加CPU或SSD：这类问题加资源无效，需重构热点索引或拆分热点表
基线对比真正的价值不在“看出异常”，而在于过滤掉负载自然波动，把注意力钉死在“同负载下效率下降”的真实退化点上——这点容易被忽略，但恰恰是AWR区别于普通监控的关键。
