升级后不可直接比对11g与19c的AWR报告，因统计口径、采样粒度、等待事件归类、SQL聚合方式均不一致；必须用19c的awrrpt.sql回刷11g快照生成统一基线，再比对DB Time/AAS、Parse Time Elapsed、Physical Reads Direct三项绝对值是否阶跃偏移，并用DISPLAY_AWR验证SQL执行计划漂移。
升级后直接比对 AWR 报告会得出错误结论，因为 11g 和 19c 的统计口径、默认采样粒度、等待事件归类逻辑、SQL 统计聚合方式均不一致；必须用同一套基线快照 + 同一工具链（19c 的 awrrpt.sql）回刷旧数据，再交叉比对关键指标的绝对值与分布形态。
为什么不能直接拿11g报告和19c报告并排看
11g 的 DB Time 不包含后台进程（如 LGWR、CKPT）的 CPU 消耗，而 19c 默认计入；db file sequential read 在 11g 中合并了单块读+小范围多块读，在 19c 中已拆分为 db file sequential read 和 db file scattered read；更隐蔽的是：SQL ordered by Elapsed Time 页面中，11g 对硬解析失败的 SQL 会丢弃统计，19c 则保留为 UNPARSEABLE 并计入总耗时——这会导致“慢 SQL 数量”在升级后看似激增，实为统计覆盖更全。
必须用19c的awrrpt.sql回刷11g快照
升级完成后，立刻执行以下操作，否则旧快照将无法被新版本正确解析：
- 确认 11g 快照仍存在于
SYSAUX表空间：运行SELECT COUNT(*) FROM dba_hist_snapshot WHERE snap_id BETWEEN 1000 AND 2000（替换为你关心的区间） - 用 19c 的 SQL*Plus 连接数据库，执行
@?/rdbms/admin/awrrpt.sql，在提示“Enter value for report_type”时选html - 当提示“Enter value for num_days”时，输
0，然后手动输入起止snap_id（必须是升级前采集的 11g 快照 ID） - 生成的 HTML 报告，其所有指标（包括
AAS、DB CPU、等待事件分类）都按 19c 规则重算，这才是可比基线
重点比对的三项不可调和指标
不是看“占比”，而是盯住三个绝对值是否发生阶跃式偏移：
-
DB Time / Elapsed Time（即 AAS）：若 11g 基线 AAS=1.8，升级后同负载下升至 3.5，说明并发处理效率下降，需查latch: cache buffers chains或cursor: pin S wait on X是否新增 -
Parse Time Elapsed总耗时：19c 引入自适应游标共享（ACS），若该值翻倍且parse count (hard)未同步增长，大概率是 ACS 频繁触发 plan regeneration，应禁用optimizer_adaptive_features -
Physical Reads Direct：11g 中该指标常为 0（因 direct path 逻辑未完全启用），19c 下若突增且伴随direct path read temp等待，说明 PGA 设置过小或排序/哈希操作被迫落盘
SQL执行计划漂移必须用DISPLAY_AWR验证
AWR 报告里的 “SQL ordered by Elapsed Time” 只显示平均值，掩盖了计划跳变。真正要确认是否因升级引发漂移，得手动查：
SELECT plan_hash_value, COUNT(*), MIN(snap_time), MAX(snap_time)
FROM dba_hist_sqlstat s
JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id
WHERE sql_id = 'your_sql_id'
AND sn.snap_time > TO_DATE('2026-10-20', 'YYYY-MM-DD')
GROUP BY plan_hash_value;
如果返回多行，再用 DBMS_XPLAN.DISPLAY_AWR('sql_id', NULL, NULL, 'ADVANCED') 分别提取各 plan_hash_value 的完整计划，重点比对 Note 区域是否出现 dynamic sampling used for this statement（19c 默认开启动态采样，11g 关闭）或 optimizer_features_enable 版本标记变化。
最易被忽略的是：19c 的 AWR 默认不采集 V$SQL_PLAN_STATISTICS_ALL 级别的运行时统计（如 actual rows、buffer gets per row），所以即使看到某条 SQL 的 Elapsed Time Per Exec 升高，也无法判断是计划变差还是数据分布突变——必须搭配 ASH 采样点下钻，否则所有归因都是猜测。
