直接查v$active_session_history中event='enq: tx - row lock contention'且blocking_session非空的记录，可精准定位持锁会话；v$session易因状态残留误判，awr采样粒度粗（10秒）且滞后，无法捕获秒级锁爆发。
直接查 v$active_session_history 里带 blocking_session 且事件为 enq: TX - row lock contention 的记录，就能定位真实锁源头——不是“谁在等”，而是“谁在持锁且没释放”。
为什么不能只看 v$session 或 AWR？
很多 DBA 一查 v$session 发现 blocking_session 非空就动手 kill，结果发现那个会话早已断开，状态残留导致误判。AWR 更慢，默认每 10 秒采样一次、还只保留活动会话，几秒内的锁爆发根本捕不到。v$active_session_history 是内存中滚动的秒级录像带，只要没被覆盖（通常保 30–60 分钟），就能精准回溯到哪一秒、哪个 SID、哪条 SQL 正卡在持锁状态。
常见错误包括：
- 查
v$session时漏加status = 'ACTIVE'，把已断连但未清理的僵尸会话当真阻塞源 - 用
dba_hist_active_sess_history却不缩时间窗口，扫全表卡死，还可能因权限不足报错 - 只关注等待方，忽略持锁方可能已
ON CPU或WAITING但尚未被其他会话标记为 blocking
怎么从 ASH 找出真正的持锁会话？
锁等待的本质是“一个会话持有资源，另一个会话在等它释放”。ASH 里真正能指认持锁者的线索，是同时满足以下三点的采样行：
-
event = 'enq: TX - row lock contention'且blocking_session IS NOT NULL - 该
blocking_session对应的另一行，在同一sample_time下sid = blocking_session且event不是等待事件（比如是ON CPU或SQL*Net message from client） - 两个会话的
current_obj#相同或相近，sql_id高度相似（说明操作同一张表/同业务逻辑）
实操建议用这个查询快速聚焦：
SELECT sample_time, sid, blocking_session, event, sql_id, current_obj#
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/1440
AND event = 'enq: TX - row lock contention'
AND (blocking_session IS NOT NULL OR sid IN (
SELECT blocking_session
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/1440
AND blocking_session IS NOT NULL
))
ORDER BY sample_time DESC;
如何验证是不是事务未提交导致的锁？
90% 的行锁问题根因是应用端事务没提交，而不是 SQL 本身有问题。确认方法很直接：
- 拿到持锁会话的
sid和serial#，查v$session：SELECT sql_id, prev_sql_id, status, logon_time, last_call_et FROM v$session WHERE sid = <sid> AND serial# = <serial></serial></sid> - 若
status = 'INACTIVE'且last_call_et超过几分钟，基本可断定是应用连接空闲但事务未 commit/rollback - 进一步查它最后执行的 SQL：
SELECT sql_text FROM v$sql WHERE sql_id = '<pre class="brush:php;toolbar:false;" v_sql_id>'</pre>，看是不是UPDATE或DELETE后没跟COMMIT - 别信
v$locked_object里的xid—— 它只显示当前持有锁的事务号，但无法告诉你这个事务来自哪个应用线程或 IP
容易被忽略的关键细节
RAC 环境下必须用 gv$active_session_history，否则跨节点的持锁会话完全看不到；blocking_session 字段在 RAC 中必须配合 blocking_instance 一起判断，单看 SID 会串号。另外，enq: TX - row lock contention 的 p1 和 p2 是 undo segment# 和 slot#，如果两个互锁会话的 p1/p2 值刚好交叉相等（A.p1 = B.p2 且 B.p1 = A.p2），基本就是死锁前兆，不是普通阻塞——这时得立刻查 trace 文件，ASH 只能帮你定位到秒级现场，不能替代 Oracle 自动死锁检测机制。
