gc cr block lost和gc current block lost真正指向私网通信故障，本质是ipc send timeout或udp重传失败；gc buffer busy acquire/release是延迟引发的连锁反应，平均等待>5ms且频率突增时需警惕；gc cr/current block 2-way属正常开销，不可误判为故障。
AWR里哪些gc等待事件真正指向私网问题
不是所有gc等待都等于心跳异常，但gc cr block lost和gc current block lost出现就基本能断定私网通信已出问题。这两个等待的本质是IPC send timeout——请求发出去后没收到响应，触发重传，不是块真丢了，而是底层UDP包被丢弃或延迟超限。
gc buffer busy acquire和gc buffer busy release也常高发，但它们是结果而非根源：当远端块传输卡住，后续进程争抢同一buffer，才堆出这类等待。如果Avg global cache cr block receive time超过10ms（比如1473ms），那gc buffer busy大概率就是传输慢引发的连锁反应。
要避开误判：gc cr block 2-way、gc current block 2-way属于正常开销，不能直接等同故障；gc cr multi block request则多见于全表扫描场景，需结合db_file_multiblock_read_count和UDP缓存大小一起看。
重点盯AWR里哪两个统计位置
别在Top SQL或Instance Efficiency里找原因，直奔RAC Statistics和Global Cache Stats两部分：
-
Avg global cache block receive time (ms)：正常应20ms已需警惕，>100ms基本确认私网延迟严重 -
Estd Interconnect traffic (KB)：平时几百KB/s属正常，若突增至几MB/s（如24 MB/s），说明Cache Fusion流量暴增，常见于MTU不匹配、丢包或带宽不足导致重传堆积 - 顺手扫一眼
Global Cache Load Profile里的Blocks served和Blocks received比值，若某节点接收量远大于服务量，说明它正在被动“拉块”，可能已是瓶颈节点
OS层必须验证的三项证据
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测试巨帧，每次+1试到失败为止；返回Frag needed and DF set (mtu = X)就说明超限 - 查
/var/log/oracle/crsd/ocssd.log，搜missco或时间戳异常的missed heartbeat记录，这是集群心跳丢包最直接的日志证据
UDP socket缓冲区设置不当的典型表现
Oracle RAC的Global Cache流量是突发性的，OS UDP接收缓冲区（udp_recvspace）太小，会导致内核来不及处理入包，直接丢弃——这时gc cr block lost会飙升，但网络设备本身可能完全无报错。
不同系统参数名不同，但原则一致：
- AIX上：确保
udp_recvspace≥(db_block_size * db_file_multiblock_read_count) + 4096，且udp_sendspace≤udp_recvspace - Linux上：检查
net.ipv4.udp_mem和net.core.rmem_max，实际生效值取rmem_default和rmem_max中的较小者 - 改完必须重启数据库实例才能生效，仅reload内核参数无效
这块最容易被忽略：DBA盯着AWR调SQL、调LMS进程数，却忘了OS层UDP缓冲区早被压爆了——而日志里既没错误也没警告，只有gc cr block lost默默上涨。
