应查GV$ACTIVE_SESSION_HISTORY，因其每秒采样、含final_blocking_instance和final_blocking_session字段，可直击级联阻塞最上游持锁者，且支持RAC环境精准定位。
查 GV$ACTIVE_SESSION_HISTORY 而不是 V$SESSION 或 DBA_HIST_ACTIVE_SESS_HISTORY
单靠 v$session 只能看到“此刻谁在等谁”，但级联阻塞（比如 A → B → C）常在采样间隙中动态演进，blocking_session 字段最多链一级，且 RAC 下不带 blocking_instance 就直接丢掉跨节点环节。而 dba_hist_active_sess_history 是 10 秒采样一次、入库有延迟，死锁或级联锁常在 1–2 秒内完成，历史表大概率只留下断裂快照。
必须用 gv$active_session_history，它每秒采样（内存中保留约 1 小时），且含 final_blocking_instance 和 final_blocking_session——这两个字段指向最上游的持锁者，跳过中间转发节点，直击根源。
- 执行时务必加
inst_id或final_blocking_instance过滤，否则 RAC 下结果混杂多实例数据 - 时间窗口别拉太宽：
sample_time > SYSDATE - 5/1440（最近 5 分钟）足够，再宽噪音剧增 - 避免全表扫：
WHERE event = 'enq: TX - row lock contention' AND final_blocking_session IS NOT NULL是最精简起点
用 final_blocking_session + final_blocking_instance 定位根阻塞会话
final_blocking_session 不是普通 blocking_session，它是 Oracle 内部递归解析后确认的“源头”，哪怕中间经过 3 层转发，这个字段也直接指向第一个没被任何人阻塞、却在持锁的会话。配合 final_blocking_instance，就能立刻知道该去哪个实例连上去查实时状态。
- 如果
final_blocking_session = 0或为空，说明根阻塞者不是普通会话，可能是后台进程（如 SMON 清理事务）、未提交的批处理作业、或已断开但事务未回滚的僵死连接 - 查到
final_blocking_instance = 2、final_blocking_session = 1058后，立刻切到实例 2 执行：SELECT sid, serial#, username, status, sql_id, event, logon_time FROM v$session WHERE sid = 1058 - 重点看
status：若为INACTIVE，说明会话已退出但事务残留；若为ACTIVE且event是SQL*Net message from client，基本可断定应用端没发commit
验证锁资源是否一致：别只看 final_blocking_session，要对齐 P1/P2 和 CURRENT_OBJ#
多个会话显示同一 final_blocking_session，不代表它们真被同一个资源阻塞——得验证锁对象是否重叠。对 enq: TX - row lock contention，关键看 p1（undo segment#）和 p2（slot#）：
- 若两个会话的
p1和p2互换（A.p1 = B.p2 且 B.p1 = A.p2），基本可确认 TX 锁互持，是死锁实锤 -
CURRENT_OBJ#可不同（锁不同行），但若反复出现在同一sql_id下，优先检查该 SQL 的事务边界和绑定变量使用 - 注意区分
enq: TX - row lock contention（行锁）和enq: TX - allocate ITL entry（ITL 不足），后者不是真锁冲突，调优方向完全不同
查到根会话后，必须立刻关联 V$TRANSACTION 看 used_ublk
ASH 告诉你“谁在持锁”，但不告诉你“持了多久、占了多少 undo”。一个 INACTIVE 会话可能已断开，其事务却仍在占用大量 undo 段，持续阻塞别人。
- 立即执行：
SELECT s.sid, s.serial#, s.username, s.program, t.used_ublk, t.start_time FROM v$session s JOIN v$transaction t ON s.taddr = t.addr WHERE s.sid = &sid ORDER BY t.used_ublk DESC -
used_ublk单位是数据库块（通常 8KB），>10000 表示已用超 80MB undo 空间，属高风险 - 若
username为空但program是oracle@host (J000)，说明是 job 进程在跑未提交的批量操作
真实阻塞源头往往藏在“已退出但未清理”的事务里，而不是正在执行的活跃 SQL 上。这点最容易被忽略，一上来就 kill session，反而可能触发更大范围的 undo 回滚风暴。
