查GV$CLUSTER_INTERCONNECTS只能看到Oracle声明使用的网卡，无法反映真实GC流量；需结合tcpdump抓HAIP UDP包、iftop看节点间实时流量、ethtool -S查驱动级丢包来准确定位问题。
查 GV$CLUSTER_INTERCONNECTS 只能看网卡，不能看流量
很多人一上来就查 gv$cluster_interconnects，看到它返回了 bond1 或 eth2 就以为“知道走哪张卡了”，其实这只说明 oracle 声明用了这张网卡，完全不反映真实流量压力。这张视图甚至不记录任何字节计数，也无法区分 gc 流量和心跳、cssd 通信等其他私网流量。
真正要盯的，是操作系统层面的实时载荷——因为 Oracle 的 GC 流量最终落地为 UDP 包（RAC 11.2+ 默认）或 TCP（部分老版本或显式配置），而这些包必须经过内核协议栈。
- 别信
GV$SYSSTAT里gc cr blocks received这类计数：它们只告诉你“逻辑块次数”，没带时间戳、没带大小、没上下文，无法换算成 KB/s -
GV$INTERCONNECT_PINGS是伪指标：它测的是 ping 延迟，不是 GC 包实际传输耗时，且默认每 5 秒才发一次，完全跟不上业务毛刺 - AWR 报告里的“估计互联网络流量(KB)”是估算值：基于平均块大小（通常按 8KB 算）× 块数，但真实 GC 包含 TCP/UDP 头、IP 头、以太网头，实际线缆字节数比这个高 15%–20%
用 tcpdump 抓真实 UDP 流量，必须匹配 HAIP 和端口范围
RAC 11.2.0.2+ 默认启用 HAIP（169.254.x.x），所有 GC 流量都走这个虚拟地址，而不是你配置的静态私网 IP（如 192.168.1.11）。直接抓后者，tcpdump 会一无所获。
正确命令要同时满足三个条件：指定 HAIP 地址、限定 UDP 协议、过滤双向通信：
tcpdump -i bond1 -n udp and host 169.254.23.37 and host 169.254.23.38 -w gc_udp.pcap
-
-n必须加：避免 DNS 反查拖慢捕获，也防止时间戳被干扰 - 不能用
port 1521：GC 不走监听端口，而是动态端口（通常在 32768–65535），但也不建议用portrange 1024-65535——会混入 NTP、DHCP 等无关 UDP 流量 - 必须写两个
host：只写一个方向（比如只写src host A）会漏掉反向 ACK 或响应包，导致流量低估 40% 以上 - 抓包后用 Wireshark 打开，过滤
udp.length > 100：GC 包一般 ≥ 128 字节，排除 ICMP、ARP 等小包噪音
用 iftop 实时看节点间流量分布，重点识别偏斜
iftop 能告诉你“谁和谁在传、传多快”，这对定位 GC 热点对极有用。GC 流量不是均匀分布在所有节点之间，往往集中在某一对（比如 node1 ↔ node3），而其他链路几乎空闲。
运行命令（假设 GCS/GES 默认端口是 6200/6201）：
iftop -P tcp -f "port 6200 or port 6201" -i bond1
- 观察 “TX” 列：如果 node1 → node3 的发送速率长期是 node1 → node2 的 5 倍，那 node3 很可能正承担大量 block 请求，需查该节点上是否有未绑定变量的循环 SQL
- 注意单位：
iftop默认显示 B/s，不是 KB/s；按P键可切换为 KB/s，避免误读数量级 - 别只看峰值：用
-t参数导出文本日志（iftop -t -L 1000 -P ...），再用 awk 统计 5 分钟滑动窗口均值，比瞬时值更可靠 - 若发现某对节点间流量突增但
GV$SQL没对应高 buffer_gets 语句，大概率是后台进程（如 LMS、LMON）在做 cache fusion cleanup，需查GV$SESSION_EVENT中gc cr block busy的等待分布
用 ethtool -S 查丢包和驱动异常，比 Oracle 统计早 2–3 层
Oracle 的 gc cr block lost 等统计项，是在应用层（LMS 进程）发现超时后才累加的，此时问题已穿透 TCP 栈、到达网卡驱动甚至物理链路。而 ethtool -S bond1 输出里的字段，能提前暴露底层问题：
-
rx_discards或tx_aborted_errors非零：基本锁定为网卡驱动 bug 或交换机 QoS 限速，和 Oracle 配置无关 -
rx_long_length_errors> 0：说明 MTU 不一致（比如一端设 9000，另一端仍是 1500），会导致大包被丢弃，GC 性能断崖下跌 -
rx_crc_errors持续增长：物理链路有问题（光纤衰减、模块兼容性），不是调参数能解决的 - 对比
ifconfig bond1的 RX bytes 和ethtool -S bond1的rx_bytes：前者含以太网头/CRC（L2），后者是驱动接收的真实字节数；若差值长期稳定在 40–60 字节/包，说明 TCP/IP 栈工作正常；若差值忽大忽小，说明有中间设备（如 ToR 交换机）做了策略性丢包
HAIP 地址、UDP 协议、驱动级丢包——这三个点串起来，才能看清 Cache Fusion 流量的真实水位。光看数据库视图，就像只听发动机声音判断车速，而忘了看油表、转速表和轮胎胎压。
