查v$active_session_history看不到跨节点GC等待，因为ASH默认只采集本实例数据，gc current block 2-way是远程实例发起的等待，本地实例不记录请求方信息；需查gv$active_session_history或连接各实例分别查询。
查 v$active_session_history 时为什么看不到跨节点 GC 等待？
因为默认只捕获本实例的 ash 数据，gc current block 2-way 是远程实例发起的等待，本地实例上它表现为 gc cr block 2-way 或根本没被记录——尤其当请求方在节点2、响应方在节点1时，节点1的 ash 不会记录“自己在服务谁”。
- 必须连接到所有 RAC 实例分别查
v$active_session_history，不能只看当前连接的实例 - 更可靠的方式是查
gv$active_session_history（全局视图），但要注意：它不保证实时聚合，部分行可能延迟数秒甚至丢失 - 确认
ASH采样是否开启：SELECT value FROM gv$parameter WHERE name = 'statistics_level' AND value != 'TYPICAL'，非TYPICAL或ALL会导致 GC 相关等待不采集
gc current block 2-way 在 ASH 中对应哪些列和过滤条件？
它属于 event 列的值，但要注意大小写和空格：实际值是 'gc current block 2-way'（带单引号，全小写，含空格），不是 GC_CURRENT_BLOCK_2WAY 或其他变体。
- 核心过滤条件：
event = 'gc current block 2-way'，且session_state = 'WAITING' - 关键辅助列：
inst_id（发生等待的实例）、blocking_inst_id（若为 0 表示无直接阻塞者；若为其他值，说明该等待由另一实例触发） - 别忽略
p1text/p1：对gc current block 2-way，p1text是file#，p1是具体文件号，可关联到数据文件定位热点对象 - 注意时间范围：ASH 默认保留约 1 小时（受
_ash_disk_filter_ratio和内存限制影响），长周期问题建议结合 AWR 报告交叉验证
用 ASH 定位网络延迟，而不是单纯看等待次数
等待次数高 ≠ 网络慢；真正反映延迟的是 time_waited（单位：微秒）和连续等待的持续性。RAC 节点间千兆/万兆网络下，单次 gc current block 2-way 理论耗时应
- 不要只算 COUNT(*)，要查
AVG(time_waited)/1000（转为毫秒），并按sample_time分组看趋势 - 对比同一时间段内
gc cr block 2-way的平均等待时间：如果两者都高，大概率是网络或 interconnect 问题；如果只有current高，可能是某节点上的块被频繁修改（如索引叶节点争用） - 检查
wait_class是否为Cluster，排除误判成System I/O或Network类等待 - 用
SELECT DISTINCT inst_id, blocking_inst_id FROM gv$active_session_history WHERE event = 'gc current block 2-way' AND time_waited > 5000快速识别异常实例对
为什么开了私网 Bonding 还有高延迟？ASH 显示的 blocking_inst_id 总是 0
因为 blocking_inst_id 在 gc current block 2-way 场景下多数为 0 —— Oracle 并不总把发送方记为 blocker，尤其在 2-way 协议中，等待发生在请求方，而服务方只是响应，ASH 不强制关联双向链路。
- 此时需转向底层验证：用
oifcfg getif确认私网接口配置，再在各节点运行ping -s 8192 <remote_private_ip></remote_private_ip>测大包丢包/抖动 - 检查
netstat -s | grep -i "retransmit"，重传率 > 0.1% 就可能影响 GC 效率 - 留意
gv$cluster_interconnects中的status，若为DOWN或UNKNOWN，ASH 中的等待归因会失真 - 11gR2+ 可查
gv$sysmetric_summary中指标Global Cache Average CR Get Time和Global Cache Average Current Get Time，比单条 ASH 更稳定反映趋势
GC 等待的根因从来不在 ASH 一行记录里，它只是个指针；真正要拆开看的是私网 MTU、UDP 缓冲区、RAC heartbeat 间隔、甚至交换机 QoS 设置——ASH 告诉你“哪里疼”，但解剖刀得拿去操作系统和网络设备上找。
