AWR中SQL Parse Time变长根本原因是硬解析泛滥，19c因统计更严格、latch争用更敏感、绑定捕获更细粒度而使其更显性；确认方法是查v$sql中字面量SQL或DBMS_XPLAN中Peeked Binds为空。
AWR 中 SQL Parse Time 变长，不是升级本身导致的“新问题”，而是旧问题在 19c 下更显性、更易被暴露——根本原因仍是硬解析泛滥，只是 11g 里可能被掩盖，19c 的统计更严格、默认行为更敏感。
为什么升级后 Parse Time 在 AWR 里突然变高？
11g 时代很多系统靠“共享池够大+负载不高”硬扛硬解析，问题不明显；19c 对 library cache latch 争用更敏感，mmon 进程采集解析耗时更细粒度，且默认启用 _cursor_bind_capture_area_size 更小（1mb），导致绑定变量捕获失败率上升，进一步放大了“没用绑定变量”的痕迹。
-
v$sqlarea.parse_calls / executions比值在 19c AWR 报告中更容易突破 0.8 —— 不是因为变多了，而是原来漏统计的部分现在被计入 -
Parse CPU和Parse Elapsed差值变小，说明 CPU 成为瓶颈主因，而非 I/O 或锁等待，这和 19c 默认启用更多并行解析校验有关 - 19c 的
cursor_sharing默认仍是EXACT，不像某些 11g 补丁版本会悄悄设成FORCE，所以字面量 SQL 不再被自动改写，硬解析直接暴露
怎么确认是不是绑定变量缺失？
别只看 v$sql_bind_capture 是否为空——它默认关闭，且只缓存最近 15 分钟活跃绑定值。更直接的办法是查 v$sql 本身：
- 运行
SELECT sql_id, sql_text FROM v$sql WHERE sql_text LIKE '%WHERE id = %' AND sql_text NOT LIKE '%WHERE id = :%';，结果非空就铁证 - 对高
parse_calls的sql_id执行DBMS_XPLAN.DISPLAY_CURSOR('&sql_id', NULL, 'PEEKED_BINDS')，如果Peeked Binds部分为空，且sql_text里全是字面量，就是应用层没传绑定变量 - 检查 JDBC 驱动是否仍用 11g 的旧版（如
ojdbc6.jar），某些老驱动在 19c 上会退化为字符串拼接模式，绕过 PreparedStatement 绑定机制
shared_pool_size 调大能缓解吗？
不能治本，反而可能延缓问题暴露。增大 shared_pool_size 只会让硬解析后的执行计划在内存里多留一会儿，但每次执行仍要走完整硬解析流程，CPU 开销照旧。
-
v$sgastat中library cachefree memory 若长期低于 50MB，说明共享池碎片化严重，但根源仍是大量不同字面量 SQL 涌入 - 盲目调大
shared_pool_size后，AWR里Hard Parses/sec数值可能暂时下降（因为淘汰变慢），但Parse CPU占比不会降，甚至因 latch 争用加剧而升高 - 真正该动的是
cursor_sharing：设为FORCE可临时兜底（注意测试执行计划变化），或设为SIMILAR（19c 中已废弃，慎用）
升级后最容易被忽略的配置陷阱
很多 DBA 查完绑定变量就收工，却漏掉两个 11g→19c 的隐式变化：
-
_optimizer_adaptive_plans在 19c 默认开启，它会动态调整执行计划，但前提是 SQL 复用执行计划——如果每次都是硬解析，这个特性完全不生效，反而增加解析开销 -
optimizer_features_enable如果没显式设回'11.2.0.4'，19c 优化器会按新规则解析 SQL，对未绑定变量的语句生成更复杂的校验路径（比如额外做谓词重写检查），单次硬解析耗时从 11g 的 ~5ms 升到 12–18ms -
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings修改快照间隔后，若没同步清理旧快照，WRH$_SQLSTAT等表膨胀会导致解析元数据扫描变慢，间接拖慢硬解析初始化阶段
WHERE order_id = 123。19c 只是把镜子擦得更亮了。 
