Oracle如何识别锁等待？利用ASH查找Blocked Session-Oracle-PHP中文网

v$active_session_history可回溯1小时内每秒的锁等待，需查event含'enq: %'且session_state='waiting'、wait_class='concurrency'的记录，结合p1/p2解码定位具体锁对象。

如何用v$active_session_history查blocked session

ash不是实时视图，但它是诊断锁等待最可靠的“回溯依据”——尤其当阻塞已结束、v$session里找不到blocking_session时，ash能还原过去1小时内每秒的会话状态。

关键点：ASH只记录ACTIVE会话，且采样间隔默认1秒；若会话在采样瞬间处于enq: TX - row lock contention或enq: TM - contention等等待事件中，就会留下痕迹。

必须确保STATISTICS_LEVEL = 'TYPICAL'或'ALL'（BASIC会禁用ASH）
查询范围受限于ASH buffer大小（通常几MB），默认最多保留约30分钟数据，超时即被覆盖
不能直接查“谁被谁锁”，需结合blocking_session和blocking_session_serial#字段反向关联

常用SQL：

SELECT sample_time,
       session_id,
       session_serial#,
       blocking_session,
       blocking_session_serial#,
       event,
       p1text, p1,
       p2text, p2,
       sql_id
FROM v$active_session_history
WHERE event LIKE 'enq: %'
  AND sample_time > SYSDATE - 1/24  -- 查最近1小时
ORDER BY sample_time DESC;

为什么v$session.blocking_session有时为空却仍有锁等待

常见现象：执行SELECT * FROM v$session WHERE blocking_session IS NOT NULL返回空，但业务明显卡顿、应用日志报超时。这往往是因为阻塞已解除，但锁等待过程短暂而密集，v$session快照没捕获到那一瞬。

根本原因在于v$session是动态视图，内容随会话状态实时刷新；而ASH是内存中滚动采样的历史快照，只要采样时刻会话正在等锁，就一定有记录。

Ai Session Analysis

用于分析本地AI编程助手会话数据（如Claude Code、Codex、Kimi Code）。当用户请求分析编程会话时触发。

下载

v$session.blocking_session只反映“当前”阻塞关系，毫秒级变化都可能错过
ASH中blocking_session字段同样可能为NULL——不是没阻塞，而是采样时阻塞源刚好完成提交或回滚
真正可靠的是event + session_state = 'WAITING' + wait_class = 'Concurrency'三者组合

ASH中识别TX/TM锁等待的关键字段

Oracle锁等待事件在ASH里以enq:前缀标识，但仅看event列不够，必须结合p1、p2解码资源ID，才能定位具体对象或行。

event = 'enq: TX - row lock contention'：典型行锁，p1是锁类型+模式（高16位为type，低16位为mode），p2是usn
event = 'enq: TM - contention'：表级锁，p1是object_id，可联dba_objects查表名
p3在TX锁中常为row_wait_file#
不要依赖current_obj#字段判断锁定对象——它反映的是当前SQL访问的对象，不一定是锁持有对象

快速定位被锁表：

SELECT DISTINCT o.object_name, o.object_type
FROM v$active_session_history h
JOIN dba_objects o ON h.p1 = o.object_id
WHERE h.event = 'enq: TM - contention';