awr报告中出现gc cr block lost或gc current block lost可断定私网通信异常；avg global cache block receive time>10ms即表明私网延迟严重，estd interconnect traffic突增至mb/s级说明流量暴增。
awr 报告里出现 gc cr block lost 或 gc current block lost，基本可断定私网通信已出问题；光看平均等待时间或 sql 慢，不能直接归因于心跳延迟。
盯紧 RAC Statistics 和 Global Cache Stats 里的两个关键指标
别在 Top SQL 或 Instance Efficiency 里找答案。重点看这两个位置：
-
Avg global cache block receive time (ms)：正常应 -
Estd Interconnect traffic (KB)：平时几百 KB/s 属正常；若突增至几 MB/s（比如 24 MB/s），说明 Cache Fusion 流量暴增，常见于 MTU 不匹配、丢包或带宽不足引发重传堆积
顺手扫一眼 Global Cache Load Profile 中的 Blocks served 和 Blocks received 比值：若接收远大于服务，说明某节点正在被动“拉块”，可能已是瓶颈节点。
哪些 gc 等待事件真正指向私网延迟
不是所有 gc 等待都等于私网坏，但以下这几个高频率 + 高平均等待，基本可锁定底层通信异常：
-
gc cr block lost和gc current block lost：最典型。不是块真丢了，是请求发出后超时未收响应，本质是 IPC send timeout 或 UDP/TCP 重传失败 -
gc buffer busy acquire/gc buffer busy release：块卡在传输途中，后续进程争抢同一 buffer 导致等待堆叠，是延迟引发的连锁反应 -
gc freelist block busy：较少见，但若集中出现在某节点，可能该节点收包队列积压，ksxp消息队列满，Avg message sent queue time on ksxp (ms)会同步飙升
注意：gc cr block 2-way 或 gc current block 2-way 属正常开销，不能直接等同于故障。
必须下到 OS 层交叉验证，AWR 只反映结果
AWR 说有问题，但真因得靠操作系统证据确认。别信 ethtool 显示 “Link detected” 就万事大吉：
- 跑
netstat -s | grep -i "reasm\|frag\|drop"，重点看IpReasmFails是否持续增长——99% 是 MTU 不匹配（一端设 9000，交换机或对端仍是 1500） - 用
ping -c 2 -M do -s 8972 node2-priv测试巨帧：从 8972 开始试，+1 失败就停；若返回Frag needed and DF set (mtu = X)，说明已超限 - 查
oifcfg getif确认当前生效的 interconnect 接口，再用tcpdump -i <ifname> 'host <peer-ip> and port 6200'</peer-ip></ifname>看 GCS/GES 流量是否真走该网卡
特别注意：crsctl stat res -t 里 ora.cluster_interconnect.haip 资源 offline，即使物理链路 up，也大概率是多播注册失败——交换机 IGMP Snooping 未配 querier 是常见原因。
改 MTU=9000 不等于延迟下降，三件事缺一不可
很多团队改完 ip link set dev eth1 mtu 9000 就以为搞定，结果延迟照旧。必须同时满足：
- 端到端支持 Jumbo Frames：查
ethtool eth1的Supports jumbo frames: Yes；驱动参数如modinfo ixgbe | grep jumbo要确认启用 - Oracle 进程读取新缓冲区值：LMS 启动时硬读 MTU，运行中改不生效；必须先
crsctl stop crs全集群停机，再统一设 MTU，最后启动 - UDP 流量真实走巨帧：用
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u抓包验证——只看到 8972 或接近值才算成功；若全是 1500 左右，说明链路某处（常是交换机端口）卡在 1500
最容易被忽略的是：sysctl net.ipv4.ip_forward = 0 必须关转发，否则私网 UDP 包可能被误路由；还有 /proc/sys/net/core/rmem_max 若小于 24M，需设为 25165824 并 sysctl -p，且必须重启数据库实例才生效。
