GV$CLUSTER_INTERCONNECTS仅显示OCR中静态注册的网卡名称，不反映实时流量路径、字节数、丢包率等负载指标，无法判断实际Interconnect使用情况。
GV$CLUSTER_INTERCONNECTS只告诉你用了哪张网卡，不反映实时流量
这个视图返回的是ocr里静态注册的interconnect接口配置，不是当前实际收发包的路径。常见错误是看到gv$cluster_interconnects里显示bond1就认定所有gc流量都走它——但haip（169.254.x.x）可能已漂移到bond2，而该视图不会更新。更关键的是，它完全不包含字节数、包数、丢包率等任何负载指标。
实操建议：
- 先运行
oifcfg getif确认当前生效的cluster_interconnect接口名 - 再用
ip addr show核对对应接口是否UP且有HAIP地址（169.254.x.x/16） - 若
GV$CLUSTER_INTERCONNECTS和oifcfg getif结果不一致，说明OCR未同步，需执行oifcfg setif并重启CRS
查真实Interconnect流量得看/proc/net/dev，不是GV$SYSSTAT
GV$SYSSTAT里的gc cr blocks received等指标统计的是逻辑块请求次数，单位是“块”，不是字节；而Interconnect带宽瓶颈关心的是每秒传输多少MB。两者不能直接换算——因为一个block request可能触发多个UDP包（含SCN同步、lock消息），也可能被合并。
实操建议：
- 用
cat /proc/net/dev读取物理网卡L2层收发字节数，注意这是含以太网头+CRC的原始字节数 - 计算时减去
rx_packets * 42（估算以太网开销），再除以时间间隔，得到接近TCP载荷的MB/s - 对比
ethtool输出的协商速率（如10000baseT/Full），若持续高于70%才需警惕带宽饱和
tcpdump抓不到GC包？大概率是没抓HAIP地址
RAC 11.2+默认所有GC流量都走HAIP（169.254.x.x），而不是你在/etc/hosts里配的私网IP（如192.168.10.x）。直接tcpdump -i bond1 host 192.168.10.2必然为空。
实操建议：
- 先执行
ifconfig | grep 169.254找出本节点HAIP，再用oifcfg getif确认对端节点HAIP - 抓包命令必须指定HAIP：
tcpdump -i bond1 -n udp and host 169.254.23.37 and host 169.254.23.38 - 若仍无包，检查交换机IGMP Snooping是否启用且未配置querier——HAIP依赖多播注册，多播不通则GC流量静默失败
AWR里“Interconnect Traffic per Second”数值偏低，不代表没问题
AWR报告中的这个值是各节点GV$SYSSTAT中GC相关统计的加权汇总，单位是KB/sec，但它会过滤掉非block级的GCS/GES控制消息（如GRANT、CANCEL、SCN广播）。这些小包虽单个体积小，但频率高，对延迟和中断分布更敏感。
实操建议：
- 当AWR显示
Interconnect Traffic仅2–3 MB/sec却出现gc cr block busy等待突增时，优先查GV$EVENT_HISTOGRAM中16ms分桶占比 - 用
hping3 -c 10 -p 6200 -S测TCP SYN延迟，比ping更贴近GCS真实路径 - 检查
ethtool -S里的rx_discards、tx_aborted_errors，非零值直接指向网卡驱动或交换机QoS限速
