必须用awrddrpt.sql而非手动对比两份awrrpt.sql，因其强制对齐快照边界、统一归一化基准（如每事务）、标出%Diff和↑↓箭头；手动对比易因快照不连续、时间偏差92秒、并发变化致统计口径漂移而误判。
直接用 awrddrpt.sql 对比升级前后的两个时间段，是定位 oracle 升级后性能下降最可靠的方式；靠人工翻两份 awrrpt.sql 报告逐页比对，90% 会漏掉快照错位、时间漂移或统计口径不一致导致的假象。
为什么必须用 awrddrpt.sql 而不是手动对比两份 awrrpt.sql
升级后性能下降往往藏在“看似正常”的数字里。手动对比容易踩三个坑：
- 快照编号不连续：比如升级后问题时段用了
snap_id12345–12346，而你选的“升级前基线”误用了 12200–12201，中间跳过 144 个快照，负载趋势断裂，根本看不出变化拐点 - 时间对齐偏差：两份报告都写“14:00–15:00”，但实际采集快照可能差 92 秒，
ASH样本错位，enq: TX - row lock contention这类瞬时争用被平均抹平 - 统计口径漂移：升级前后并发会话数从 50 涨到 200，
Execs per Sec的分母翻了 4 倍，同一 SQL 的“每秒执行次数”看起来降了，其实是并发能力提升——但你误判为退化
awrddrpt.sql 在生成时强制对齐快照边界、统一按“每事务”或“每秒”归一化，并在差异列直接标出 %Diff 和 ↑↓ 箭头，比如 DB Time per Txn: +187% 或 library cache: mutex X↑，避免主观误读。
运行 awrddrpt.sql 前必须确认的 3 个前提
脚本执行失败或结果失真，通常是因为以下任一条件没满足：
- 两个时间段必须属于同一数据库实例：
SELECT dbid FROM v$database确认一致；跨 PDB 对比需先ALTER SESSION SET CONTAINER = pdb_name，否则awrddrpt.sql默认查 CDB$ROOT，数据混杂 - 两个时间段内不能有实例重启：运行
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (start_snap, end_snap)，若startup_time不一致，整段对比无效 - 两个时间段长度建议严格相等（如都是 3600 秒）：否则
DB Time per Sec类指标因分母不同失真；若必须不等长（如升级窗口只有 20 分钟），就只盯per txn或total列，忽略所有带 “/Sec” 的行
怎么看懂 awrddrpt.sql 输出里的关键差异
对比报告不是堆数字，核心是识别“哪些指标变差了，且变化是否真实显著”：
-
%Diff列值 > |20%| 且绝对值足够大才值得深挖：比如DB Time增加 1200 秒、Physical Reads per Txn+420%，但Parse CPU to Parse Elapsed %: -0.3%直接忽略 - 重点关注带 ↑↓ 箭头的行：
db file sequential read↑表示单块读响应变慢或访问暴增；library cache: mutex X↑直接指向硬解析风暴或游标共享失效；SQL ordered by Elapsed Time页里，看Elapsed Time per Exec是否同步上升——若只升Execs per Sec而不升单次耗时，大概率是业务量涨了，不是 SQL 变慢 - 特别留意自动索引相关信号：Oracle 19c 升级后若
Top SQL执行计划从TABLE ACCESS FULL变成INDEX RANGE SCAN但耗时暴涨，立刻查DBA_AUTO_INDEX_CONFIG和DBMS_AUTO_INDEX.REPORT_ACTIVITY()，低区分度字段（如status只有 'Y'/'N'/'P'）上建的SYS_AI_xxxx索引常是元凶
真正难的不是跑出报告，而是判断哪一行 %Diff 是噪声、哪一行 ↑ 是根因——这取决于你是否清楚升级前后业务负载特征、SQL 访问模式和底层存储配置。别迷信箭头，要结合 v$sql_plan 和 dba_hist_sqlstat 交叉验证。
