AWR对比需严格对齐快照时间窗口、确保STATISTICS_LEVEL=TYPICAL/ALL、结合ASH定位瞬时尖峰，并关联应用变更分析根因，否则指标失真且无法解释变化原因。
AWR快照时间范围选不对，对比就失去意义
oracle的awr报告本质是采样快照的差值计算，如果两个时段的起止时间没对齐（比如一个从09:15开始、另一个从09:17开始），db time、logical reads等关键指标会因采样窗口偏移而失真——尤其在负载波动剧烈时，误差可能高达30%以上。
实操建议：
- 用
dba_hist_snapshot查准快照ID：SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot WHERE begin_interval_time >= TRUNC(SYSDATE)-1 ORDER BY snap_id DESC;
- 对比必须用相同长度的窗口（如都是60分钟），且起始快照ID和结束快照ID都要严格对应
- 避免跨天或跨AWR保留周期（默认8天），否则
dba_hist_*视图可能已归档或清理
直接看Top SQL不如先盯住DB Time分解
很多人一上来就翻SQL ordered by Elapsed Time，但若整体DB Time没明显增长，单条SQL变慢可能是并发挤压或锁等待导致，而非SQL本身劣化。真正该优先看的是Instance Efficiency Percentages和Wait Classes by Total Wait Time。
实操建议：
- 先确认两份AWR中
DB Time是否同比上升：如果+50%，但CPU Time只+5%，大概率是I/O或锁问题 -
DB CPU占比骤降 +User I/O飙升 → 检查physical reads和cell flash cache read hits是否异常 - 出现大量
Concurrency类等待（如enq: TX - row lock contention）→ 不是SQL要调优，是应用事务设计或索引缺失
对比时忽略Active Session History（ASH）会漏掉瞬时尖峰
AWR每小时只存1次快照，而真实业务尖峰常持续几秒到几分钟。比如凌晨批处理触发的2分钟高负载，在AWR里可能被平滑成“平均”指标，看不出压力来源。
实操建议：
- 用
DBMS_WORKLOAD_REPOSITORY.ASH_REPORT_TEXT生成对应时段的ASH报告，重点看Top Events和Top SQL with Top Events - ASH中
session_state = 'WAITING'且event重复出现 > 100次/分钟，基本可定位为瓶颈事件 - 结合
v$active_session_history查具体会话堆栈：SELECT sql_id, event, p1text, p1, COUNT(*) FROM v$active_session_history WHERE sample_time BETWEEN TO_DATE('2024-04-01 02:10','YYYY-MM-DD HH24:MI') AND TO_DATE('2024-04-01 02:12','YYYY-MM-DD HH24:MI') GROUP BY sql_id, event, p1text, p1 ORDER BY COUNT(*) DESC;
AWR对比结果不准？检查STATISTICS_LEVEL和采集粒度
如果数据库启用了STATISTICS_LEVEL = BASIC，AWR根本不会收集pga_aggregate_target、sga_target等内存相关统计，所有与内存争用相关的分析都会失效；而默认1小时采样间隔，在OLTP系统里也容易掩盖秒级抖动。
实操建议：
- 确认当前设置：
SHOW PARAMETER STATISTICS_LEVEL，必须是TYPICAL或ALL - 临时提升采样频率（仅限诊断）：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 15)（单位分钟） - 注意：修改后新快照才生效，历史快照无法补采；且
interval设太小会加重SYSAUX表空间压力
AWR不是万能的对比工具——它只告诉你“哪里变了”，不解释“为什么变”。最常被忽略的是应用层变更：新上线的定时任务、连接池配置调整、甚至JDBC驱动升级，都可能让同一SQL执行计划突变。别只盯着数据库端，把DBA_HIST_SQL_PLAN和应用日志对上时间戳，才能闭环。
