存储过程编译卡住且查不到阻塞会话，是因为library cache lock作用于共享池对象句柄，v$locked_object不显示该锁；需通过v$db_object_cache查locks/pins，并结合v$session和dba_scheduler_jobs定位执行中会话或自动统计任务。
为什么存储过程编译会卡住，且查不到阻塞会话？
因为 library cache lock 不是传统意义上的 DML 锁（比如 enq: TX），它作用在共享池的对象句柄上，v$locked_object 完全不显示这类锁。当你看到存储过程编译长时间挂起、会话状态为 LIBRARY CACHE LOCK 等待，或报 ORA-04021，基本可以确定是其他会话正持有该过程的 handle 锁——但那个会话可能早已结束、只留下一个未清理的 pin，或者正在执行长耗时调用。
怎么快速定位正在运行/被依赖的存储过程？
关键不是查“谁在编译”，而是查“谁在用它”。运行中的 PL/SQL 过程会在 v$db_object_cache 中体现为非零的 pins 或 locks：
SELECT owner, name, type, locks, pins FROM v$db_object_cache WHERE name = 'YOUR_PROC_NAME' AND type = 'PROCEDURE';- 若
pins > 0，说明有会话正在执行它（哪怕只是刚调用、还没返回）；若locks > 0且pins = 0，可能是某会话刚完成编译但未释放句柄，或存在未提交的 DDL 依赖链 - 配合
v$session查当前活跃会话：SELECT sid, serial#, sql_id, event, blocking_session FROM v$session WHERE event = 'library cache lock' AND program NOT LIKE '%sqlplus%';—— 注意blocking_session字段在此类等待中**可能为空**，不能依赖它
如何确认是不是因统计信息收集或调度任务触发的？
大量 library cache lock 常与 DBMS_SCHEDULER 自动任务强相关，尤其是 gather_database_stats_job_proc 这类操作会批量刷新对象元数据，引发连锁重编译：
- 查当前活跃自动任务：
SELECT job_name, state, last_start_date, next_run_date FROM dba_scheduler_jobs WHERE job_name LIKE 'GATHER%STATS%'; - 查问题时段的调度执行记录：
SELECT job_name, status, actual_start_date, error# FROM dba_scheduler_job_run_details WHERE actual_start_date BETWEEN SYSDATE-1/24 AND SYSDATE ORDER BY actual_start_date DESC; - 如果发现
FRIDAY_WINDOW或WEEKEND_WINDOW在业务高峰时段运行，立刻调整其REPEAT_INTERVAL—— 例如改到凌晨 1 点：DBMS_SCHEDULER.SET_ATTRIBUTE('SYS.FRIDAY_WINDOW', 'REPEAT_INTERVAL', 'freq=daily;byday=FRI;byhour=1;byminute=0;bysecond=0');
容易被忽略的两个深层原因
一是绑定变量传入 NULL 触发子游标爆炸：当存储过程中调用的 SQL 使用了 VARCHAR2 类型绑定变量且值为 NULL，Oracle 可能为每个 NULL 生成独立子游标（Bug 8198150），导致共享池碎片化、加载锁争用加剧；二是跨数据库链接（dblink）调用时，远端库的 DDL 操作会通过依赖链反射回本地库缓存，造成隐式锁等待——这种场景下 blocking_session 往往显示为 KILLED，但实际阻塞源在远端。
