应查GV$GES_BLOCKING_ENQUEUE而非GV$SESSION，因其由LMD进程直接维护，真实反映GES层跨节点资源争用；需过滤INST_ID并解析RESOURCE_NAME1/2定位锁类型，结合V$TRANSACTION还原事务全貌，P3值则用于快速识别library cache lock等非行锁根因。
查 GV$GES_BLOCKING_ENQUEUE 而不是只看 GV$SESSION
GV$SESSION 的 blocking_session 字段在 RAC 下容易失真，尤其对瞬时 GC 等待或已释放锁的会话；真正可靠的跨节点阻塞链藏在 v$ges_blocking_enqueue 里。它由 LMD 进程直接维护，反映 GES 层真实资源争用状态。
执行时必须加 INST_ID 过滤，否则可能混入其他实例无关数据：
SELECT inst_id, state, resource_name1, resource_name2,
granting_inst_id, requesting_inst_id,
sid, serial#
FROM gv$ges_blocking_enqueue
WHERE state IN ('BLOCKING', 'WAITING')
AND inst_id = 1;
-
resource_name1格式如TX-000A0001-00000F4C，前缀TX-表示事务锁，后两段是usn.slot和wrap#.sequence#，需用TO_NUMBER('00000F4C','XXXXXXXX')反查dba_rollback_segs或v$transaction -
resource_name2若为US-xxxxxx，说明是 undo segment 争用，大概率是长事务未提交，而非 SQL 写法问题 -
granting_inst_id ≠ requesting_inst_id才是真正的跨节点阻塞，单节点内阻塞不会触发 GES 协调
用 XID 关联 v$transaction 还原事务全貌
死锁报错（ORA-00060）本身不带 SQL 绑定值，也不含行级上下文，但两个冲突事务的 XID 一定同时出现在 v$transaction 中。这是唯一能串起完整 DML 链的锚点。
拿到 gv$ges_blocking_enqueue 中的 sid 后，立刻切到对应实例查：
SELECT xidusn, xidslot, xidsqn, start_time, used_ublk, status FROM v$transaction WHERE ses_addr IN ( SELECT saddr FROM v$session WHERE sid = &blocking_sid );
-
XIDUSN/XIDSLOT/XIDSQN拼成完整 XID（如0x000A.0001.00000F4C），用于 LogMiner 解析归档日志 -
status = 'ACTIVE'且used_ublk > 100表明事务已修改大量块，大概率是未提交的批量操作 - 别依赖
sql_id字段——事务中可能混用多条 SQL，v$transaction才记录事务起点
解析 P3 值定位 Library Cache Lock 类型
当阻塞表现为 library cache lock（非行锁但卡住编译/认证），关键不是查 SQL，而是立刻解 p3：它是十六进制，格式为 100 * mode + namespace。0x4f0003 → mode=3、namespace=79，意味着 ACCOUNT_STATUS 认证锁，和 SQL 完全无关。
必须用 GV$ACTIVE_SESSION_HISTORY 实时抓，DBA_HIST_ACTIVE_SESS_HISTORY 会漏掉 90% 的跨节点 blocking_session：
SELECT inst_id, sample_time, sql_id, p3,
blocking_instance, blocking_session
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;
- namespace=1 → CRSR（游标），查
v$sqlarea的version_count > 50且executions - namespace=2 → TABLE/PROCEDURE，检查
dba_objects.last_ddl_time是否集中在问题时段 - namespace=79 → ACCOUNT_STATUS，立刻跑
dba_audit_session查returncode = 1017（密码错）高频重试
KILL SESSION 不生效？先确认 LMD 进程状态
RAC 中执行 ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE 后仍卡住，大概率不是会话没杀掉，而是 LMD 进程本身 hang 或 CPU 超载，无法广播 kill 指令。
验证方式很简单：
SELECT inst_id, pid, spid, program, status, cpu_time FROM gv$process WHERE program LIKE 'lmd%';
- 若某节点
cpu_time持续飙升或status = 'STOPPED'，LMD 已异常 - 此时
kill -9对应 OS 进程（spid）比数据库命令更有效，但需 DBA 权限且影响全局锁协调 - 别反复重试 kill —— LMD 卡住时，重复指令只会堆积等待队列，加剧私网压力
跨节点阻塞最麻烦的不是找不到源头，而是误判锁类型：把 library cache lock 当成 SQL 问题去优化，或把 US-xxxxxx undo 争用当成索引缺失来加索引，都会让问题拖得更久。P3 和 resource_name2 是第一眼必须看的字段，它们比 SQL_ID 更早暴露根因。
