应直接查GV$ACTIVE_SESSION_HISTORY定位持锁会话：聚焦event='library cache lock'且sql_opname为DDL操作、p1text/p2text为handle/lock address、blocking_session非空且对应DDL编译类操作，并结合sql_text确认；RAC必须用GV$，避免依赖DBA_HIST；物化视图刷新需atomic_refresh=>FALSE并满足FAST刷新条件；绑定变量传NULL会导致子游标爆炸，须应用层拦截。
怎么快速定位持锁会话而不是等在AWR里猜
AWR报告里library cache lock排高，不代表它就是根因——它只是阻塞链末端的“症状”。真正要抓的是那个没释放锁的会话，不是一堆在等的会话。
直接查GV$ACTIVE_SESSION_HISTORY（RAC必须用GV$，单实例可用V$），聚焦三类关键信号：
-
event = 'library cache lock'且sql_opname IN ('CREATE', 'ALTER', 'DROP', 'GRANT', 'REVOKE') -
p1text = 'handle address'且p2text = 'lock address'—— 这才是真实持锁点 -
blocking_session非空，且对应会话的sql_opname是CREATE OR REPLACE PACKAGE或ALTER VIEW
如果sql_id为空，别停——立刻用session_id关联v$session查sql_text。DDL编译阶段常无sql_id，但sql_text里一定有CREATE OR REPLACE或GRANT SELECT ON这类字样。
物化视图刷新卡住时怎么绕过TRUNCATE锁
默认DBMS_MVIEW.REFRESH走atomic_refresh => TRUE，本质是先TRUNCATE再INSERT，触发独占library cache lock，所有查该物化视图甚至基表的会话全卡住。
改用atomic_refresh => FALSE可降为行级锁，但前提很硬：
-
user_mviews.fast_refreshable必须返回'FAST'（不是'FAST_SNAPSHOT'） -
user_mview_logs里得有对应日志：SELECT log_table FROM user_mview_logs WHERE master = 'SALES'不能为空 -
user_mview_analysis.capable_flag不能有'N'项（比如缺失主键、远程表、未建日志）
执行示例：DBMS_MVIEW.REFRESH('MV_SALES', method => 'F', atomic_refresh => FALSE)。不满足条件时，Oracle会静默退化成COMPLETE刷新，反而更慢更锁。
RAC环境下为什么查本节点ASH会漏掉真凶
RAC中library cache lock等待常跨节点发生，但V$ACTIVE_SESSION_HISTORY只返回本节点数据。一个节点上执行CREATE OR REPLACE PACKAGE，另一个节点查同名包，就会等在library cache lock上——而你在本节点ASH里根本看不到持锁会话。
必须用GV$ACTIVE_SESSION_HISTORY，且确保查询覆盖所有节点。如果无法连全部实例，至少要在每个节点上单独跑以下语句：
SELECT sql_id, sql_opname, event, p1text, p1, p2text, p2, blocking_session
FROM gv$active_session_history
WHERE event = 'library cache lock'
AND sample_time > SYSDATE - 1/24
AND sql_opname IN ('CREATE','ALTER','DROP');别信DBA_HIST_ACTIVE_SESS_HISTORY——它是采样汇总，已丢失blocking_session和p1/p2细节，定位不了持锁点。
绑定变量传NULL为什么会引发几千个子游标和锁争用
Oracle对VARCHAR2类型绑定变量传NULL时，会为每个NULL生成独立子游标（Bug 8198150），导致v$sql里出现几万个CHILD_ADDRESS，共享池碎片化，硬解析激增，进而推高library cache lock等待。
验证方式：
- 查
v$sql_bind_capture，看datatype_string是否为VARCHAR2且value_string为空 - 查
v$sql中同一sql_id的version_count是否异常高（比如>100） - 查
v$sql_shared_cursor里大量BIND_MISMATCH但类型一致
解决不在数据库端——应用层需拦截NULL值，改用空字符串''或预设默认值。数据库侧加bind_aware或关ACS都无效，这是底层绑定处理逻辑缺陷。
最常被忽略的点：持锁会话可能早已ON CPU但不动，session_state不是WAITING；v$db_object_cache.locks > 0的对象未必正在被修改，可能是编译卡在依赖校验环节；RAC中FLUSH SHARED_POOL不是解药，而是放大器。
