如何解决Oracle因段合并造成的Library Cache Lock性能问题？

SHRINK SPACE 本身不直接引发 Library Cache Lock，但会因使依赖 cursor 失效并触发大量硬解析，导致 library cache lock 等待飙升；其根源是 DDL 后的连锁重解析，而非 shrink 操作持锁。

段合并（segment shrink / alter table ... shrink space）本身不直接引发 library cache lock，但会隐式触发对象失效和硬解析连锁反应——真正卡住系统的，是 shrink 后大量 sql 因依赖表结构变更而重新解析。

为什么 SHRINK SPACE 会连带 Library Cache Lock 高等待

SHRINK SPACE 是 DDL 操作，执行时 Oracle 会对目标表加独占锁，并在完成后自动使所有引用该表的 cursor 失效。这些失效的 cursor 下次执行时必须硬解析，而硬解析需获取 library cache lock —— 若并发高、SQL 未绑定变量、共享池碎片化，就会瞬间堆积大量 library cache lock 等待。

• 不是 shrink 操作本身持锁太久，而是它“引爆”了后续成百上千个硬解析请求
• AWR 中常看到 library cache lock + cursor: pin S wait on X 同时飙升，这是典型失效-重解析链路
• v$session_wait.event = 'library cache lock' 的会话，p1raw 值通常指向表名或视图句柄，而非 shrink 语句本身

快速定位是否为 SHRINK 引发的连锁失效

别只查正在 shrink 的会话（它早就结束了），重点抓 shrink 后那批“被波及”的 SQL：

• 查 AWR 报告中 SQL ordered by Version Count：版本数 > 50 且 sql_text 含目标表名的语句，大概率就是失效重解析主力
• 运行：

  SELECT sql_id, version_count, sql_text FROM v$sql WHERE sql_text LIKE '%<your_table_name>%'   AND version_count > 20 ORDER BY version_count DESC;

• 结合 v$db_object_cache 确认该表是否刚被 shrink：

  SELECT name, type, locks, pins FROM v$db_object_cache WHERE name = '<TABLE_NAME>' AND type = 'TABLE';

  若 locks > 0 或近期 pins 波动剧烈，说明缓存正被高频重建

避免 shrink 后 Library Cache Lock 爆发的实操动作

核心原则：不让失效扩散，不给硬解析留空子。

• shrink 前先禁用相关 SQL 的自动失效：执行 ALTER SYSTEM SET "_optimizer_adaptive_plans"=FALSE（非必需，但可减少计划变更引发的额外 reload）
• shrink 后立刻对关键对象做显式 reload：用 DBMS_SHARED_POOL.KEEP 将常用包、视图句柄 pin 住，防止它们被挤出共享池
• 临时启用游标共享（仅限应急）：ALTER SYSTEM SET cursor_sharing = FORCE SCOPE=MEMORY，等业务低峰再切回 EXACT 并推动应用改绑定变量
• 绝对不要在 shrink 后立刻跑 DBMS_STATS.GATHER_TABLE_STATS：统计信息收集本身也持 library cache lock，叠加硬解析会雪上加霜；建议错开 10 分钟以上

比 kill session 更有效的缓解方式

当已出现大面积等待，别急着杀解析中的会话——它们只是受害者。优先干预源头：

• 查出持有锁的“真凶”：用 p1raw 关联 x$kglob 找到被频繁访问的表/视图句柄，然后查 v$access 看谁在编译依赖对象
• 如果发现是某个 PL/SQL 包正在重编译（sql_opname = 'PL/SQL EXECUTE'），且该包引用了刚 shrink 的表，直接 ALTER PACKAGE ... COMPILE 强制完成，比等它自己超时更可控
• 确认无活跃事务后，可对共享池做局部清理：EXEC DBMS_SHARED_POOL.PURGE('<schema>.<table_name>', 'T')（注意类型是 'T'），比 flush 全局安全得多

最易被忽略的一点：SHRINK SPACE 默认开启 CASCADE 时，会递归 shrink 所有依赖索引和物化视图——这些对象的失效会进一步放大 library cache lock 范围。执行前务必显式指定 SHRINK SPACE COMPACT 或关闭 cascade，否则你以为只动了一张表，实际锁住了半个 schema。