必须查gv$active_session_history，因其能聚合rac所有实例数据并含blocking_instance字段，精准定位跨节点阻塞源；限定最近5分钟、过滤row lock contention事件；需结合gv$ges_blocking_enqueue和lmd0_*.trc日志交叉验证死锁。
必须查 GV$ACTIVE_SESSION_HISTORY，不是 v$active_session_history
单实例视图 v$active_session_history 在 RAC 下根本看不到跨节点的持锁会话——比如实例 2 上的会话 A 持有行锁，实例 1 上的会话 B 正在等它，v$active_session_history 在实例 1 上查不到 A 的任何采样记录。只有 GV$ACTIVE_SESSION_HISTORY 能聚合所有实例数据，且含 blocking_instance 字段，明确标出阻塞源在哪台节点上。
漏查 blocking_instance 是 RAC 死锁误判的第一大原因：你以为没阻塞源，其实是它在隔壁实例。
- 限定时间窗口：用
SAMPLE_TIME > SYSDATE - 5/1440（最近 5 分钟），死锁常在秒级发生，历史表采样太稀疏 - 过滤真实死锁事件：
event = 'enq: TX - row lock contention'，排除enq: TX - allocate ITL entry（ITL 不足，非死锁） - 关键动作：找同一
SAMPLE_TIME下互指的两条记录——A 的BLOCKING_SESSION = B.SID，B 的BLOCKING_SESSION = A.SID - 验证资源互持：比对
P1（undo segment#）和P2（slot#），若 A.P1= B.P2且 B.P1= A.P2，基本锁定为同一事务资源交叉持有
直接定位 GES 层转储：查 lmd0_*.trc，不是 _ORA_*.trc
RAC 全局死锁的决策逻辑全在 GES（Global Enqueue Service）层，_ORA_*.trc 里没有死锁路径；真正 dump 出关键上下文的是 lmd0_*.trc（Lock Manager Daemon 进程日志），路径在 Diag Trace 目录下，文件名形如 inst1_lmd0_12345.trc。
grep -A 10 -B 5 "DEADLOCK" inst1_lmd0_*.trc 可快速提取包含 *** GES DEADLOCK DETECTED *** 的段落，重点看：
- 每个会话的
INST_ID和GRANT_LEVEL（X 表示排他锁，S 表示共享锁）——跨实例 X→S 或 S→X 升级冲突是高频诱因 - “DID = X_Y_Z” 字段，这是全局死锁标识符，可用于关联
gv$ges_blocking_enqueue中的阻塞链 - TRACE 中不含 SQL 绑定值或行级上下文，这是架构限制，不是日志配置问题
用 gv$ges_blocking_enqueue 抓实时阻塞链，别只盯 v$lock
v$lock 在 RAC 下无法反映 GES 层的 enqueue 状态，查到的只是本地锁快照，极易漏掉远程阻塞。必须用 gv$ges_blocking_enqueue，它能暴露哪个实例上的哪个资源（如 TX-000A0001-00000F4C）正被谁持有、又被哪个远程实例的会话请求。
典型查询要带状态过滤：
SELECT inst_id, event, state, blocking_inst_id, resource_name1, resource_name2, sid, serial#
FROM gv$ges_blocking_enqueue
WHERE state IN ('BLOCKING', 'WAITING');
-
resource_name1是锁类型+对象 ID（如TX-000A0001-00000F4C），不是表名；需用TO_NUMBER('00000F4C','XXXXXXXX')反查dba_objects - 若
blocking_inst_id != inst_id，说明阻塞来自另一个节点——这是单实例脚本永远查不到的 -
resource_name2常藏根因：以US-开头表示 undo segment 争用，意味着事务未及时提交，导致其他实例读一致性请求失败
查到会话后，立刻验证 XID 和事务状态，ASH 不代表当前活跃
GV$ACTIVE_SESSION_HISTORY 只告诉你“谁在等谁”，但不保证事务还在跑——Oracle 自动 rollback 牺牲者后，BLOCKING_SESSION 字段会被清空，ASH 里只剩单边快照。
必须立刻连上对应实例（用 blocking_instance 确认节点号），执行两步验证：
- 查
gv$transaction：确认两个会话的XID是否仍在活跃事务列表中 - 查
gv$session：用SID和SERIAL#确认STATUS——INACTIVE说明已被 kill，ACTIVE才是真正在跑 - 别信
SQL_ID是否相同：死锁双方可能执行不同 SQL，但更新了同一张表的主键/唯一键，导致行锁交叉
最易被忽略的点：死锁检测默认 60 秒（由 _lm_dd_interval 控制），这期间多个实例的锁请求已在 GES 中堆积，看到的 ASH 快照只是“结果切片”，不是“完整路径”。必须结合 GES TRACE + gv$ges_blocking_enqueue + gv$transaction 三者交叉印证，缺一不可。
