查 gv$active_session_history 必须带 inst_id 过滤，否则 RAC 下仅查当前实例漏其他节点冲突；ASH 采样敏感于短时尖峰，需结合 session_id、sql_id、blocking_session、inst_id 定位跨节点阻塞源。
查 gv$active_session_history 要带 inst_id 过滤
不加 inst_id 就等于只看当前连接的实例，漏掉其他节点的会话冲突。ash 数据默认按实例隔离，v$active_session_history 是单实例视图，rac 下必须用 gv$active_session_history，且 where 条件里明确指定或分组统计 inst_id。
常见错误现象：SELECT COUNT(*) FROM v$active_session_history WHERE event LIKE 'enq:%' —— 这条语句在节点1上执行，只返回节点1的锁等待，完全看不到节点2正在被节点3长时间阻塞。
实操建议：
- 用
gv$active_session_history替代v$前缀视图 - WHERE 中必须包含
inst_id IS NOT NULL或具体值（如inst_id IN (1,2,3)） - 聚合分析时，务必
GROUP BY inst_id，否则 sum 后的“平均等待时间”毫无意义
ASH 报告中重点关注 enq: TX、enq: TM 和 gc current block busy
这三类事件是 RAC 会话冲突最典型的信号，但含义不同，不能一概而论：
-
enq: TX：事务级锁冲突，多见于主键/唯一键争用、位图索引更新、无索引外键删除——本质是业务 SQL 设计问题，和 RAC 架构无关，但在多节点并发下放大效应 -
enq: TM：表级锁，通常由 DDL（如 ALTER TABLE）或未提交的 DML 引发，RAC 下跨实例传播更快，容易卡住多个节点的会话 -
gc current block busy：说明某节点正持有数据块的当前模式（current mode），其他节点在等它释放；不是锁本身，而是 Cache Fusion 传输链路卡顿，根源常在 Interconnect 延迟或 LMS 进程繁忙
注意：gc cr block 2-way 属于正常流程，高频率不等于冲突；但若伴随高 gc current block busy，就说明“读请求撞上了写持有”，需结合 sql_id 定位具体语句。
用 ASH 抽样定位冲突源头 SQL
ASH 每秒采样一次，对短时尖峰冲突（如秒级锁等待）比 AWR 更敏感。关键是把 session_id、sql_id、blocking_session、inst_id 四个字段串起来查。
实操建议（替换 &start_time 和 &end_time 为实际时间戳）：
SELECT inst_id,
sql_id,
event,
COUNT(*) AS sample_count,
MAX(blocking_session) AS blocking_sid,
MAX(blocking_inst_id) AS blocking_inst
FROM gv$active_session_history
WHERE sample_time BETWEEN TO_DATE('&start_time', 'YYYY-MM-DD HH24:MI:SS')
AND TO_DATE('&end_time', 'YYYY-MM-DD HH24:MI:SS')
AND event IN ('enq: TX', 'enq: TM', 'gc current block busy')
GROUP BY inst_id, sql_id, event
ORDER BY sample_count DESC;
重点看 blocking_inst 是否跨节点（比如本节点是 2，blocking_inst 是 1），确认是真 RAC 冲突，而非单实例内锁。
别忽略 blocking_session_status 和 in_parse/in_hard_parse
有时看到 blocking_session 非空，但查 gv$session 发现对应会话已不存在——这是 ASH 采样快照与实时状态的时间差导致的。此时要查 blocking_session_status 字段：
-
VALID：真正在阻塞，可继续追sql_id -
INVALID：阻塞源已结束，当前会话可能在自旋重试或等待超时 -
UNKNOWN：大概率是 GC 类事件（如gc current block busy），没有传统意义上的“持有者会话”，而是 LMS 进程在协调，得转去看gv$latchholder或gv$sysstat中的 GC 统计
另外，如果冲突会话的 in_parse=1 或 in_hard_parse=1 占比高，说明大量会话卡在解析阶段争抢 library cache lock 或 row cache lock，这不是数据块级冲突，而是共享池资源争用，调优方向完全不同。
