必须用awrddrpt.sql生成差异报告，因其强制对齐快照边界、统一按“每事务”归一化并标出%Diff和↑↓箭头；手动对比两份awrrpt.sql易因快照不连续、时间偏差92秒、并发变化导致统计口径漂移而误判。
必须用 awrddrpt.sql，别翻两份 awrrpt.sql
手动对比升级前后的两份 awrrpt.sql 报告，90% 会误判。真正有效的做法是直接运行 awrddrpt.sql 生成一份差异报告——它强制对齐快照边界、统一归一化口径（如按“每事务”计算），并在关键指标旁标出 %diff 和 ↑↓ 箭头。你看到的 db time per txn: +187% 或 library cache: mutex x↑，才是真实变化信号。
常见错误现象：
- 选错快照范围：比如升级后问题时段是
snap_id12345–12346，却拿 12200–12201 当基线，中间跳过 144 个快照，负载趋势断裂 - 时间看似一致但实际偏差：两份报告都写“14:00–15:00”，但快照采集差了 92 秒，ASH 样本错位，瞬时争用（如
enq: TX - row lock contention）被平均抹平 - 并发变化干扰判断：升级后会话数从 50 涨到 200，
Execs per Sec看似下降，其实是能力提升，不是退化
运行 awrddrpt.sql 前必须确认的三个前提
脚本失败或结果失真，往往卡在这三点上：
-
SELECT dbid FROM v$database必须一致：跨 PDB 对比要先ALTER SESSION SET CONTAINER = pdb_name，否则默认查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↑、cursor: pin S wait on X↓—— 这些才是瓶颈线索 - 结合
Time Model Statistics节拆解DB Time构成：若sql execute elapsed time占比突增，说明 SQL 执行层出问题；若parse time elapsed暴涨，优先查硬解析（parse count (hard)是否飙升）、绑定变量缺失或cursor_sharing配置
升级后性能下降常藏在“看似正常”的数字里
比如 Top 5 Events 里 log file sync 时间没变，但 commits per transaction 翻倍了，实际 redo 写入压力已翻倍；又比如 Hard parse 比例从 1% 升到 8%，单看不吓人，但结合 executions 总量，可能每天多出 200 万次硬解析。这些细节不会自动标红，得你主动把 awrddrpt.sql 的 %Diff 和原始 AWR 报告里的绝对值、基数交叉对照。最易被忽略的是：差异报告里的 ↑ 只表示增长，不区分好坏——DB CPU↑ 可能是优化见效，enq: TX - row lock contention↑ 才是问题。
