必须用GV$ACTIVE_SESSION_HISTORY查RAC跨节点阻塞，因DBA_HIST_ACTIVE_SESS_HISTORY仅含当前实例数据且采样聚合，会漏掉90%的blocking_session；关键条件是event='library cache lock'、wait_time=0、blocking_session IS NOT NULL，并需立即解析p3定位namespace与mode。
直接查 GV$ACTIVE_SESSION_HISTORY，别只用 DBA_HIST_ACTIVE_SESS_HISTORY
ash 视图在 rac 环境下必须用 gv$active_session_history，否则 90% 的阻塞源会漏掉——因为 blocking_session 可能来自其他节点，而 dba_hist_active_sess_history 默认只查当前实例。执行时必须加 blocking_instance is not null 或显式指定 inst_id 字段。
关键过滤条件只有两个：event = 'library cache lock'、WAIT_TIME = 0（表示正卡着），再加 BLOCKING_SESSION IS NOT NULL。时间窗口建议压到 3–5 分钟内，比如：
SELECT inst_id, sample_time, sql_id, sql_plan_hash_value,
blocking_instance, blocking_session, p3
FROM gv$active_session_history
WHERE event = 'library cache lock'
AND wait_time = 0
AND blocking_session IS NOT NULL
AND sample_time BETWEEN SYSDATE - 3/1440 AND SYSDATE;注意：p3 值要立刻解出 namespace 和 mode，比如 0x4f0003 → mode=3（独占）、namespace=79（对应 ACCOUNT_STATUS），这直接决定排查方向是 SQL 还是登录审计。
解出 p3 后，立刻分路径查：SQL 类 or 认证类
p3 是十六进制，格式为 100 * mode + namespace。常见值有：
- namespace=1 →
CRSR（游标），查v$sqlarea看version_count是否 > 50 且executions极低 - namespace=2 →
TABLE/PROCEDURE，查dba_objects的last_ddl_time是否集中在问题时段 - namespace=79 →
ACCOUNT_STATUS，不是 SQL 问题，是认证风暴，立刻跑：
SELECT username, os_username, userhost, extended_timestamp, returncode FROM dba_audit_session WHERE returncode != 0 AND extended_timestamp > SYSDATE - 1/24;
常见 returncode=1017（密码错）会高频重试，每次都在 library cache 里争锁，但 SQL_ID 为空——这时候查 SQL 没用。
查到 blocking_session 后，必须切到对应节点的 v$session 实时确认
ASH 是采样，可能错过瞬时持锁。一旦从 GV$ASH 找到 blocking_instance=2、blocking_session=1058，立刻连上节点 2 执行：
SELECT sid, serial#, sql_id, sql_opname, event, state, seconds_in_wait FROM v$session WHERE sid = 1058;
重点看 sql_opname：CREATE、ALTER、DROP 直接锁定是 DDL 持锁；若 sql_id 为空但 sql_opname 是 PL/SQL EXECUTE，说明可能是包编译卡在中间态，此时查 v$db_object_cache：
SELECT name, type, locks, kept FROM v$db_object_cache WHERE name = 'PKG_NAME' AND type = 'PACKAGE';
如果 locks > 0 且 kept = 'NO'，基本就是它了。
RAC 下最易忽略的点：mutex X 和 library cache lock 别混查
Oracle 12c+ 把 library cache: mutex X 拆成了三个独立事件：library cache: mutex X、library cache: bucket mutex X、library cache: dependency mutex X。它们和 library cache lock 机制不同，不能共用同一套排查逻辑。
如果你看到的是 library cache: mutex X，就别去翻 p3 和 blocking_session——它没有阻塞链概念，得看 AWR 的 Mutex Sleep Summary，或直接抓 oradebug hanganalyze 3。混淆这两者，会浪费至少一小时在错误路径上。
