avg global cache block receive time超100ms直接暴露私网心跳延迟，是真实网络层传输耗时；estd interconnect traffic突增至24 mb/s且同步升高，大概率由mtu不匹配或udp丢包引发重传堆积。
看Avg global cache block receive time是否超100ms
这个值直接暴露私网心跳延迟，不是“平均等待”，而是真实网络层传输耗时。AWR报告末尾的Avg global cache block receive time (ms)字段必须盯紧——超过100ms基本可断定GC块传输已成瓶颈。它和gc buffer busy acquire不同：后者是争抢结果，前者才是根因信号。OLTP系统里，哪怕只在某几个快照中反复出现120–160ms，也要立刻下操作系统查。
查Estd Interconnect traffic是否突增至MB/s级
私网流量暴增不是负载高，而是UDP重传堆积的典型表现。在AWR报告的Estd Interconnect traffic (KB)项里，正常OLTP系统几百KB/s属合理；若单次快照里飙升到24 MB/s且与Avg global cache block receive time升高同步发生，大概率是MTU不匹配或UDP丢包引发。别信ethtool eth2显示的“Link detected”——链路通不等于质量稳，得看实际收发包抖动。
必须用awrrpti.sql生成per-instance报告
RAC环境下汇总报告会掩盖节点负载不均。默认awrrpt.sql输出的是全局视图，真正要定位高可用瓶颈，必须用awrrpti.sql并指定两个实例ID，生成按实例拆分的报告。否则你会看到“DB CPU占70%”却不知道这70%全压在节点1上，而节点1的cpu_count其实是节点2的两倍——真实饱和度得算DB CPU / CPU Count比率才准。
跳过gc cr block 2-way，盯死gc cr block lost
gc cr block 2-way是RAC正常开销，不是故障信号；真正指向底层网络问题的只有gc cr block lost和gc current block lost。它们本质是IPC send timeout，不是块丢了，是UDP包被丢弃或延迟超限。一旦gc cr block lost平均等待时间缓慢爬升到16–32ms桶，同时netstat -s里IpReasmFails持续增长，就是温水煮青蛙式恶化——最容易被当成“暂时波动”忽略掉。
