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 cr block lost 或 gc current block lost，基本可以停下手头其他分析——私网通信已出问题。这不是块真丢了，是ipc send timeout或udp重传失败导致请求超时。这类事件一出现，就别再怀疑sql写法或索引缺失。
gc buffer busy acquire 和 gc buffer busy release 也值得警惕，但它们属于连锁反应：块卡在传输途中，后续进程争抢同一buffer才堆起等待。若这两类事件平均等待时间 >5ms 且频率突增，大概率是底层延迟已传导上来。
注意避开干扰项：gc cr block 2-way、gc current block 2-way 是Cache Fusion正常开销，不能直接等同于故障；gc cr multi block request 高通常和全表扫描+大db_file_multiblock_read_count有关，未必是网络问题。
必须看对位置：RAC Statistics和Global Cache Stats
别在 Top SQL 或 Instance Efficiency 里找答案。重点盯死两个地方：
-
Avg global cache block receive time (ms)：正常应 10ms 就说明私网延迟严重 -
Estd Interconnect traffic (KB)：平时几百 KB/s 属正常；若突增至几 MB/s（比如 24 MB/s），说明 Cache Fusion 流量暴增，常见于 MTU 不匹配、丢包或带宽不足引发重传堆积
顺手扫一眼 Global Cache Load Profile 中的 Blocks served 和 Blocks received 比值：若某节点接收远大于服务，说明它正在被动“拉块”，可能已是瓶颈节点。
用 awrgrpt.sql 生成真正的全局报告
_awrgrpt.sql 在 RAC 上默认只查当前实例数据，会漏掉跨实例的 GC 统计。必须用 awrgrpt.sql（注意不是下划线开头的版本），并显式指定 inst_num = 0 才能生成含 Global Cache Statistics 和 Global Enqueue Statistics 的全局报告。
实操要点：
- 连入任一节点后执行
@?/rdbms/admin/awrgrpt.sql - 当提示输入 Instance Number 时，填
0（表示全部实例） - 生成后检查报告末尾是否出现
Global Cache Efficiency小节，没有就说明没走集群模式
如果坚持用 _awrgrpt.sql，必须在脚本开头手动加：DEFINE inst_num = 0;，否则它默认把 inst_num 设为当前实例号。
光看 AWR 不够，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：从 8972 开始试，+1 失败就停；返回Frag needed and DF set (mtu = X)说明已超限 -
tcpdump -i <ifname> 'host <peer-ip> and port 6200'</peer-ip></ifname>：先用oifcfg getif确认 interconnect 接口，再抓 GCS/GES 流量是否真走该网卡
最常被忽略的一点：ocssd.log 里如果有反复的 IPC send timeout 或 missed heartbeat，比任何 AWR 数值都更早暴露心跳异常。
