Oracle 12c中存储过程失效（如统计更新、DDL或FLUSH SHARED_POOL）会触发依赖SQL/PL/SQL的硬解析，导致library cache lock等待飙升；其根源是高并发下锁争用，常伴cursor: pin S wait on X、SQL Parse占比超15%，且自动统计任务（DBA_AUTOTASK_CLIENT）为静默推手。
存储过程失效触发硬解析，直接拉高 library cache lock 等待
oracle 12c 中存储过程缓存失效（比如因统计信息更新、ddl 变更或 alter system flush shared_pool）会导致依赖该过程的 sql 或 pl/sql 重新硬解析。每次硬解析必须获取 library cache lock 和 library cache pin，而这两个资源在高并发下极易争用。
常见错误现象包括：library cache lock 等待时间飙升、cursor: pin S wait on X 同时出现、AWR 报告中 “SQL Parse” 占 DB Time 超过 15%。
- 硬解析不是单次操作：一个包内多个过程被调用，可能触发多次锁申请
- 失效不等于立即重编译：首次执行时才真正触发，所以问题常在业务高峰突现
- 12c 的自适应游标共享（ACS）和多版本游标会进一步增加锁持有时间
自动任务（如统计收集）是静默推手
Oracle 12c 默认开启 auto optimizer stats collection，当它为某张表刷新统计信息时，所有引用该表的存储过程、视图、SQL 都会被标记为失效。这不是 DBA 主动操作，但后果等同于批量 DDL —— 下一次调用就强制硬解析。
典型场景：晚上 22:00 自动统计任务启动 → 次日早高峰大量存储过程首次执行 → library cache lock 等待堆积。
- 可通过
DBA_AUTOTASK_CLIENT查看是否启用：SELECT client_name, status FROM dba_autotask_client WHERE client_name LIKE '%stats%'; - ADDM 报告里若出现 “Shared Pool Latches” 竞争，大概率是这类后台任务引发的连锁反应
-
10035事件能捕获解析失败的 SQL，但仅限语法/对象级错误，对统计驱动的失效无帮助
shared_pool 尺寸不足会放大等待烈度
即使只有少量存储过程失效，如果 shared_pool 过小（比如低于建议值的 70%），新解析的对象无法稳定驻留，很快又被挤出，导致反复失效→硬解析→再失效的恶性循环。
此时 v$sgastat 中 free memory 常低于 50MB，v$librarycache 的 reloads 值持续上升，gethitratio 明显下降。
- 不要只看
shared_pool_size参数值，要结合SGA_TARGET和实际使用率判断 - 12c 的自动内存管理（AMM）下，
memory_target设置不合理也会间接压缩 shared pool - 禁用 AMM 改用 ASMM 后手动设
shared_pool_size，往往比“自动”更可控
row cache lock 会伴随出现，但根源不在字典层
有人看到 row cache lock（尤其 dc_objects）升高，误以为是对象元数据争用。实际上，在存储过程失效场景中，它往往是硬解析的副产品：解析过程中需反复查 obj$、dependency$ 表，而这些查询本身又依赖 row cache。
关键区别：row cache lock 在这里不是主因，而是 library cache lock 持有时间过长后引发的级联等待。
- 查
v$rowcache若getmisses暴涨，且集中在dc_objects，说明解析压力已传导至字典层 - 单纯调大
row_cache_count无效；必须先压住硬解析源头 -
dc_users或dc_sequences异常高？那大概率是另一类问题（如权限变更或序列争用），和存储过程失效无关
