DDL在RAC中触发跨节点library cache lock等待，因该锁由GES全局协调，一个节点执行CREATE/ALTER等DDL时会独占对象内存结构并注册为全局KQI锁，导致其他节点访问同名对象的会话被阻塞；须用GV$ACTIVE_SESSION_HISTORY查blocking_instance非本节点的记录快速定位持锁源。
DDL操作在RAC中为什么会触发跨节点library cache lock等待
因为Oracle RAC里library cache lock不是本地会话级锁，而是通过GES（Global Enqueue Service）协调的全局资源。当一个节点执行CREATE OR REPLACE PACKAGE或ALTER VIEW这类DDL时，它要独占编译对象的handle和lock address——这两个值被注册为全局enq: KQI类型锁，其他节点上任何访问同名对象（包括查询、执行、甚至编译依赖包）的会话都会被阻塞，直到DDL完成并释放锁。
这不是“锁表”或“锁行”，是锁住整个对象在library cache中的内存结构。RAC下没有共享的library cache，每个节点有独立缓存，但锁必须全局一致，所以所有争用都经GES仲裁。
怎么快速定位哪个DDL正在持锁（别等AWR）
AWR报告滞后、聚合、丢细节，真凶早跑了。直接查GV$ACTIVE_SESSION_HISTORY，只筛三类信号同时成立的记录：
-
event = 'library cache lock'且sql_opname IN ('CREATE', 'ALTER', 'DROP', 'GRANT', 'REVOKE') -
p1text = 'handle address'且p2text = 'lock address'（这是DDL编译阶段真实持锁的标志） -
blocking_session IS NOT NULL，且该会话的sql_text含CREATE OR REPLACE或GRANT SELECT ON
如果sql_id为空，立刻用session_id关联V$SESSION查sql_text——DDL编译常无sql_id，但sql_text一定暴露操作意图。
物化视图刷新为什么特别容易引发全库卡顿
DBMS_MVIEW.REFRESH默认走atomic_refresh => TRUE，本质是先TRUNCATE再INSERT，触发独占library cache lock。不只是刷MV的会话被卡，所有查该MV、甚至查其基表的会话全堵死。
改用atomic_refresh => FALSE可降为行级锁，但前提是MV**真支持FAST刷新**，不能只看创建语句写了REFRESH FAST。必须验证三件事：
-
SELECT mview_name, fast_refreshable FROM user_mviews WHERE mview_name = 'MV_SALES'返回值必须是'FAST'（不是'FAST_SNAPSHOT'） -
SELECT * FROM user_mview_analysis WHERE mview_name = 'MV_SALES'不能有capable_flag = 'N'项 -
SELECT log_table FROM user_mview_logs WHERE master = 'SALES'结果非空
不满足条件时Oracle会静默退化成COMPLETE刷新，反而更慢更锁。
RAC特有坑：为什么查本节点ASH会漏掉真凶
RAC中library cache lock等待常跨节点发生。比如节点1执行CREATE OR REPLACE PACKAGE，节点2上查同名包的会话就会等在library cache lock上——但节点2的V$ACTIVE_SESSION_HISTORY里blocking_session字段可能为空或指向本地无效会话，因为真正持锁的是远程节点上的进程。
必须用GV$前缀视图，且重点看blocking_instance列。如果blocking_instance != inst_id，说明阻塞来自另一个节点，单查本节点V$视图完全无效。
这个细节在单实例环境不存在，但在RAC里是高频盲区——很多DBA反复查本节点ASH和V$LOCK无果，就是没意识到锁源在别处。
