awrddrpt.sql比手动对比更可靠，因其强制对齐快照边界、统一归一化基准并标出变化率；手动对比易因快照不连续、时间偏差和统计口径漂移导致误判。
直接对比两份awr报告是定位性能衰退最有效的方式，但必须用 awrddrpt.sql（单实例）或 awrgdrpt.sql（rac），不能靠人眼翻页比对——90%的“看不出差异”其实是没选对基线或忽略时间粒度错位。
为什么awrddrpt.sql比手动对比两个awrrpt.sql更可靠
手动打开两份 awrrpt.sql 报告逐项对照，容易漏掉三类关键偏差：
- 快照编号不连续：比如问题时段用的是 snap_id 12345–12346，而“正常时段”误用了 12300–12301，中间跳过多个快照，导致负载趋势断裂
- 时间对齐偏差：两份报告起止时间即使都写“14:00–15:00”，实际对应快照可能因采集延迟差1–2分钟，ASH采样点错位，关键等待事件被平均抹平
- 统计口径漂移：
awrrpt.sql默认按“数据库时间（DB Time）”归一化，但若两时段并发会话数相差3倍，Top SQL的“每秒执行次数”就失去可比性
awrddrpt.sql 在生成时强制对齐快照边界、统一归一化基准（如按每秒/每事务标准化），并在差异列中直接标出变化率（如 “Logical Reads per Txn: +280%”），避免主观误判。
运行awrddrpt.sql前必须确认的3个前提
脚本执行会失败或结果失真，如果以下任一条件不满足：
- 两个时间段必须属于同一数据库实例（
dbid相同），跨PDB对比需先连接到目标PDB再运行；查当前PDB：SELECT sys_context('userenv', 'con_name') FROM dual - 两个时间段内不能有实例重启 —— 检查：
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (start_snap, end_snap) ORDER BY snap_id，startup_time 不一致则整段无效 - 两个时间段长度建议严格相等（如都是3600秒），否则报告中的“per second”类指标（如 Execs per Sec）会因分母不同而扭曲；若必须不等长，得在报告中重点看“per txn”或“total”列
看懂awrddrpt.sql输出里的关键差异标记
对比报告不是堆数字，核心是识别“哪些指标变差了，且变化是否真实显著”：
- “%Diff”列值 > |20%| 且绝对值足够大（如 DB Time 增加 1200 秒），才值得深挖；若只是 “Parse CPU to Parse Elapsed %: -0.3%”，忽略即可
- 关注带 ↑↓ 箭头的行：
db file sequential read↑ 表示索引路径变慢或访问量暴增；library cache: mutex X↑ 直接指向硬解析风暴或游标共享失效 - “SQL Statistics”页里，不要只盯 “Elapsed Time per Exec” —— 优先看 “Executions Delta” 和 “Buffer Gets per Exec Delta”，前者暴露SQL调用量突变（如定时任务误触发），后者暴露执行计划劣化（如索引失效后全表扫描）
PDB环境下对比必须切换容器再执行
在CDB中直接运行 awrddrpt.sql 默认生成CDB级对比，无法反映某个PDB的独立性能退化。真实场景中，90%的“整体正常但应用卡顿”都源于单个PDB资源争用：
- 先
ALTER SESSION SET CONTAINER = pdb1，再运行@?/rdbms/admin/awrddrpt.sql，确保所有数据源（dba_hist_*视图）走的是该PDB的AWR分区 - 对比时若发现某PDB的
log file sync等待剧增，但CDB级报告平滑，说明问题被其他PDB稀释了 —— 这正是多租户下必须PDB级对比的根本原因 - 注意：PDB级AWR数据默认保留期与CDB一致，但若该PDB曾拔插过，需确认
dba_hist_snapshot中是否存在该PDB的连续快照（查con_id列）
真正难的不是跑出对比报告，而是判断“+35% 的 CPU time”到底是因为某条SQL回归劣化，还是因为业务流量自然增长了35% —— 这需要把差异值和业务日志、应用监控（如QPS、订单量）交叉验证，否则所有技术分析都悬在半空。
