直接查v$active_session_history看不到跨节点gc current block 2-way等待，因其仅采集本实例数据，该等待实际发生在远程请求方；必须用gv$active_session_history或分别连接各实例查询，并关注time_waited、blocking_inst_id和wait_class='cluster'等关键字段。
直接查 v$active_session_history 看不到跨节点查询的真实等待，必须用 gv$active_session_history 或多实例分别查——这是 rac 下 ash 最容易踩空的第一步。
为什么单查 v$active_session_history 会漏掉 gc current block 2-way？
因为 v$active_session_history 只记录本实例的采样数据。而 gc current block 2-way 是远程实例发起的请求（比如节点2要读节点1缓存里的当前块），本地实例上它不表现为“被等待”，而是可能压根没采样到这个动作，或只记作 gc cr block 2-way 甚至不记录。
- 在节点1上执行
SELECT * FROM gv$active_session_history WHERE event = 'gc current block 2-way'，结果为空是正常的——这个事件发生在请求方（节点2），不是服务方（节点1） - 真正该查的是请求方的
gv$active_session_history：连接节点2，执行SELECT inst_id, blocking_inst_id, time_waited FROM gv$active_session_history WHERE event = 'gc current block 2-way' AND sample_time > SYSDATE - INTERVAL '5' MINUTE -
blocking_inst_id非 0 时，表示该等待由另一个实例触发；值为 0 则可能是本地块争用，不是跨节点问题
用 gv$active_session_history 分析跨节点查询延迟的关键字段
别只数等待次数，time_waited（单位：微秒）才是网络延迟的直接证据。同一时间段内，gc current block 2-way 和 gc cr block 2-way 的平均等待时间都高，才指向 interconnect 或网络问题。
-
inst_id：等待发生的实例（即“谁在等”） -
blocking_inst_id：阻塞者所在实例（即“被谁卡住”）；若为 0，说明是本地热块争用，非跨节点 -
p1text和p1：对gc current block 2-way，p1text = 'file#'，p1是文件号，可关联dba_data_files定位热点对象 -
wait_class = 'Cluster'必须校验，避免把Network或System I/O类等待误判为 GC 问题
RAC 环境下 ASH 查询必须绕开的三个坑
ASH 在 RAC 中不是天然“全局实时”的，很多看似合理的写法实际会丢数据或返回不一致结果。
- 不要依赖
gv$active_session_history的“实时聚合”——部分行可能延迟数秒甚至丢失，关键问题建议连接各实例单独查v$active_session_history - 时间条件必须用动态表达式：
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE，写死时间字符串（如'2026-05-06 13:00:00'）极易因 NLS 设置或时区偏差查不到数据 - 确认采样已开启：
SELECT value FROM gv$parameter WHERE name = 'statistics_level' AND value NOT IN ('TYPICAL', 'ALL')返回非空，说明 GC 相关等待根本不会进 ASH
跨节点查询性能问题最狡猾的地方在于：你看到的“慢”，往往不是 SQL 本身慢，而是某次 gc current block 2-way 等待卡了 200ms，而这个样本可能刚好落在 ASH 的采样间隙里——所以放宽时间窗口、查 time_waited 趋势、比对多个实例的 blocking_inst_id，比单纯 count(*) 更接近真相。
