查v$active_session_history须加sample_time和blocking_session双过滤条件，且需满足采样在问题时段、会话当前正被阻塞；区分tx争用类型应看p3值；还原阻塞链需基于连续sample_id分析；rac下必须校验blocking_instance。
查 v$active_session_history 要加 sample_time 和 blocking_session 两个过滤条件
不加时间窗口的 ash 查询会扫全内存 buffer，容易卡住或权限报错；只查 blocking_session is not null 但不校验是否正在活动，会把已断开的僵尸会话当真阻塞源。必须同时满足：采样发生在问题时段（比如最近 3 分钟），且该会话当前正被阻塞。
实操建议：
- 用
SAMPLE_TIME > SYSDATE - 3/1440限定窗口，避免全表扫描 - 加
blocking_session IS NOT NULL AND session_state = 'WAITING'，排除空闲或已完成的会话 - 别漏掉
event LIKE 'enq: TX%'或event = 'latch: cache buffers chains'这类高频争用事件
区分 index contention 和 row lock contention 的 P3 值判断法
光看 EVENT 字段为 enq: TX - row lock contention 或 enq: TX - index contention 容易误判——这两个事件在 ASH 中字段几乎一样，真正区分点在 P3。
关键判断依据：
-
enq: TX - index contention的P3一定含0x2000000标志位（十六进制） -
enq: TX - row lock contention的P3通常是0x0或很小的值（如0x123） - 若
BLOCKING_SESSION指向一个db file sequential read或latch: cache buffers chains的会话，基本是索引分裂导致的自阻塞
阻塞链不能靠 event 猜，得用 sample_id 递减构建
ASH 是滚动内存表，每秒一条记录，sample_id 严格递增。想还原真实阻塞路径，不能用 CONNECT BY PRIOR blocking_session = session_id 这种跨时间硬连的方式——那会把不同时刻的会话错误拼接。
正确做法是聚焦同一会话在连续时刻的行为：
- 先锁定一个高频率等待的
session_id和session_serial# - 查它前后几秒的样本：
SAMPLE_ID BETWEEN X-2 AND X+2 - 观察
event是否出现enq: TX - row lock contention→db file sequential read→cursor: pin S wait on X这类典型连锁 - 若多个会话都指向同一个
sql_id，且该 SQL 操作的是同一张表的主键或唯一索引列，优先检查事务是否未提交或是否存在隐式锁升级
RAC 环境下必须校验 blocking_instance
单实例查 v$session 只看 blocking_session 就够了，但在 RAC 下，阻塞者可能在另一个节点上。如果忽略 blocking_instance，会漏掉跨实例阻塞，甚至误以为没根因。
注意点：
- ASH 中的
blocking_instance字段必须和当前查询实例号比对，不能默认为 1 - 执行时显式加上
AND blocking_instance = (SELECT instance_number FROM v$instance) - 若发现
blocking_instance != instance_number，说明阻塞源头在远端节点，需登录对应实例再查v$session和v$lock - 跨实例的
enq: TX等待常伴随gc cr block busy或gc buffer busy acquire，这类组合出现时，基本可断定是 RAC 全局队列争用放大了本地阻塞
瞬时高并发阻塞最难抓的不是现象，而是“谁在等”和“谁在锁”之间的时间差——ASH 里同一秒内未必能同时捕到两者，得靠 sample_id 序列和 blocking_session 的稳定指向去反推。别信单条记录，要信连续几条。
