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;</your_table_name>
- 结合
v$db_object_cache确认该表是否刚被 shrink：SELECT name, type, locks, pins FROM v$db_object_cache WHERE name = '<table_name>' AND type = 'TABLE';</table_name>
若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')</table_name></schema>（注意类型是'T'），比 flush 全局安全得多
最易被忽略的一点：SHRINK SPACE 默认开启 CASCADE 时，会递归 shrink 所有依赖索引和物化视图——这些对象的失效会进一步放大 library cache lock 范围。执行前务必显式指定 SHRINK SPACE COMPACT 或关闭 cascade，否则你以为只动了一张表，实际锁住了半个 schema。
