<p>查ASH必须加时间窗和session_state='WAITING'双过滤，实操需满足SAMPLE_TIME > SYSDATE - 5/1440且session_state = 'WAITING'，再叠加event LIKE 'enq: TX%'等条件，漏任一结果不可信。</p>
查ASH必须加时间窗和session_state='WAITING'双过滤
不加SAMPLE_TIME的ASH查询会扫全内存buffer（默认约1小时），轻则卡住，重则因权限不足报错；只筛blocking_session IS NOT NULL但不校验是否真在等，容易把已提交或断开的僵尸会话当根因。实操必须同时满足：SAMPLE_TIME > SYSDATE - 5/1440（最近5分钟）且session_state = 'WAITING'，再叠加event LIKE 'enq: TX%'或event = 'library cache lock'。漏掉任一条件，结果就不可信——比如你看到blocking_session = 456，但它其实在8分钟前就回滚了，当前只是残留快照。
批处理阻塞业务的典型ASH特征是sql_id高频+event集中+current_obj#稳定
批处理SQL往往固定操作某张核心表（如ORDER_HEADER），ASH中会表现出：同一sql_id在短时间内（SAMPLE_ID连续几秒）反复出现在多个session_id样本里；等待事件集中在enq: TX - row lock contention或enq: TM - contention；CURRENT_OBJ#指向同一个对象ID（可用SELECT object_name FROM dba_objects WHERE object_id = 12345反查）。若该sql_id对应的是UPDATE /*+ PARALLEL */ ... WHERE batch_id = ?这类语句，基本可锁定是批处理未控制并发粒度或未分页提交导致长事务持锁。
别只看blocking_session，RAC下必须用final_blocking_session+final_blocking_instance定位真实源头
blocking_session在RAC下可能只指向本节点的中间阻塞者，真正持锁的会话在另一个实例上。final_blocking_session和final_blocking_instance才是Oracle 12c+推荐字段，它跳过A→B→C级联链，直指源头。常见错误是查到A→B→C链就kill B，结果C还在等A持有的锁。正确做法：
- 优先筛选
final_blocking_session IS NOT NULL的行 - RAC环境下必须连带查
final_blocking_instance，并用SELECT instance_number FROM v$instance确认该实例号是否有效 - 若
final_blocking_session为0或空，说明它是根阻塞源——大概率就是那个没提交的批处理会话
还原阻塞链不能靠CONNECT BY，得用sample_id递减追踪同一会话行为
ASH是滚动内存表，每秒一条记录，SAMPLE_ID严格递增。用CONNECT BY PRIOR blocking_session = session_id会强行把不同时刻的会话拼在一起，比如把上午9:45的会话A和下午3:20的会话B错误关联。真实阻塞路径得聚焦同一会话在连续时刻的行为：
- 先锁定一个高频等待的
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操作的是主键列，优先检查事务是否未提交，或是否存在隐式锁升级
