必须立刻查gv$active_session_history，ASH是唯一能实时捕获“大事务未提交”持锁证据的手段；AWR滞后稀疏，无法反映秒级阻塞链；关键查询需限定5分钟窗口、指定WAITING状态、使用gv$（RAC环境）、过滤final_blocking_session/instance，并通过p1raw区分TX锁模式及ROWID定位被锁行。
必须立刻查 gv$active_session_history，别等 AWR 报告
ASH 是唯一能抓到「大事务未提交」正在持锁的实时证据。AWR 报告滞后、采样稀疏，等它出来时，事务可能已回滚或业务已雪崩。你看到的 enq: TX - row lock contention 等待事件，在 ASH 里是秒级快照；在 AWR 里可能只留 1–2 个样本，根本看不出阻塞链。
关键操作只有一条：SELECT * FROM gv$active_session_history WHERE sample_time > SYSDATE - 5/1440 AND session_state = 'WAITING' AND event LIKE 'enq: TX%';
- 时间窗不设（即不加
SAMPLE_TIME > SYSDATE - 5/1440），会扫全内存 buffer（默认约 1 小时），轻则查询卡死，重则因权限不足报ORA-00942 -
session_state = 'WAITING'必须显式指定——排除 CPU 活跃但没真卡住的会话，否则结果全是噪音 - RAC 环境下必须用
gv$视图，v$只返回本实例数据，会漏掉跨实例持锁者
过滤 final_blocking_session 和 final_blocking_instance 才能找到根因
在 RAC 中，blocking_session 只指向本实例的中间阻塞者，不是根因。比如 A（实例2）→ B（实例1）→ C（实例1），你在实例1 查 v$active_session_history，看到 B 阻塞 C，但真正没提交的是 A——它根本不在当前实例视图里。
正确做法是强制查这两个字段：
-
final_blocking_session：真正持锁的会话 ID -
final_blocking_instance：它所在的实例号，需先用SELECT instance_number FROM v$instance确认该实例真实在线 - 若
final_blocking_session为 0 或 NULL，说明它就是根阻塞源——90% 是那个UPDATE /*+ PARALLEL */ WHERE batch_id = ?后忘了COMMIT的批处理会话
看 p1raw 值区分 mode=6（真行锁）和 mode=4（假行锁）
从 v$session 查到等待事件是 enq: TX - row lock contention 后，别急着 kill。先查 p1raw 值：
- 若
p1raw = '54580006'（后两位是 06）→mode=6→ 标准行锁：A 更新某行未提交，B 等同一行 → 杀 A 或让 A 提交即可 - 若
p1raw = '54580004'（后两位是 04）→mode=4→ 很可能不是行锁，而是唯一键冲突或 ITL 不足 → 即使杀掉等待者，下一个会话仍会报ORA-00001或继续等 - 验证是否唯一键冲突：查该
sql_id对应语句是否是INSERT INTO ... VALUES (...)，且CURRENT_OBJ#指向唯一约束所在的表
用 CURRENT_OBJ# + CURRENT_FILE# + CURRENT_BLOCK# + CURRENT_ROW# 定位被锁的具体行
ASH 记录这四个字段时，就等于给了你一把钥匙——能直接拼出被锁行的 ROWID：
SELECT DBMS_ROWID.ROWID_CREATE(1, CURRENT_OBJ#, CURRENT_FILE#, CURRENT_BLOCK#, CURRENT_ROW#) FROM gv$active_session_history WHERE event = 'enq: TX - row lock contention' AND ROWNUM = 1;
- 这个
ROWID可直接用于SELECT * FROM ... WHERE ROWID = '...';查出具体业务记录 - 结合
dba_objects.object_name查CURRENT_OBJ#对应的表名，快速锁定是哪张核心表（比如订单表、账户表）被批量更新卡住 - 注意：如果
CURRENT_ROW#为 0 或为空，大概率是 ITL 争用或唯一键冲突，不是单行被锁
最常被忽略的一点：final_blocking_session 在 ASH 里不是总出现——它只在采样瞬间恰好捕捉到完整阻塞链时才非空。所以你要查的是连续多个样本中都出现的 sql_id 和 CURRENT_OBJ# 组合，而不是依赖单行记录。
