estd interconnect traffic突增至mb/s级别（如24 mb/s）表明gc流量严重超载，主因是重传、分片或缓冲区溢出引发的“流量雪崩”，需结合gc block lost、avg global cache block receive time、blocks served/received倾斜比及ipreasmfails等指标综合诊断网络瓶颈。
看 Estd Interconnect traffic 是否突增到 MB/s 级别
AWR 里 Estd Interconnect traffic (KB) 是最直接的私网带宽使用指标。正常 RAC 私网流量是 KB/s 级别（几百 KB/s 属常见），一旦该值持续超过 1–2 MB/s（比如报告里显示 24 MB/s），基本说明 GC 流量已严重超载。这不是业务增长带来的合理上升，而是重传、分片、缓冲区溢出引发的“流量雪崩”——UDP 包被丢，LMS 不断重发，把本该一次传完的块拆成几十个包来回跑。
注意：这个值在 AWR 的 RAC Statistics 部分，不是 Load Profile 或 Instance Efficiency。别在 Top SQL 里找原因，它和 SQL 写法无关。
- 若该值比基线高 5–10 倍，且同期
gc cr block lost或gc current block lost显著上升 → 基本锁定私网带宽或 MTU 问题 - 若该值高但
gc cr block 2-way占比也高 → 更可能是某类 SQL（如大表并行扫描）触发了大量合法 GC 流量，需结合db_file_multiblock_read_count和执行计划判断 - 该值本身不反映延迟，只反映“量”。高流量 + 低延迟（
Avg global cache block receive time20ms）必须立刻干预
交叉验证 Avg global cache block receive time 是否超标
Avg global cache block receive time (ms) 在同一份 AWR 的 Global Cache Stats 表格里，它才是带宽是否“够用”的真实标尺。这个值不是理论吞吐，而是实测端到端耗时：从请求块发出，到本地收到响应块的平均毫秒数。
Oracle 官方建议阈值是 ≤ 5ms，生产环境能压到 2ms 内最佳。一旦 >10ms（比如报告里出现 1473ms），哪怕 Estd Interconnect traffic 还不到 1MB/s，也说明私网链路已出现严重瓶颈——很可能是交换机 QoS 限速、MTU 不匹配导致反复分片重传、或 UDP 接收缓冲区（udp_recvspace）被撑爆后内核直接丢包。
- 该值突增但
gc buffer busy acquire也同步飙升 → 后者是结果，不是根源；优先查网络，别调 SQL - 该值稳定在 3–4ms，但
Estd Interconnect traffic持续 8–10 MB/s → 可能是PARALLEL_EXECUTION_MESSAGE_SIZE设得过大，或并行度失控，需查 GV$SQL 中 buffer_gets/executions 高但 disk_reads/executions 极低的语句 - 该值在不同节点间差异巨大（如节点1为 18ms，节点2为 2ms）→ 直接指向单点网卡/驱动/物理链路故障，不是集群配置问题
别忽略 Blocks served / Blocks received 的倾斜比
在 Global Cache Load Profile 下，看 Blocks served（本节点服务的块数）和 Blocks received（本节点接收的块数）两个数字。健康 RAC 应该大致均衡，比值接近 1:1。如果某节点 Blocks received 是 Blocks served 的 3–5 倍以上（比如 120k vs 25k），说明它正被动“拉块”，大概率已成为 GC 流量黑洞或瓶颈节点。
这种倾斜往往和应用连接策略强相关：比如应用 TNS 配置没开 LOAD_BALANCE=on，或 service 绑定到了特定 instance，导致大部分会话集中在单节点，而它又频繁访问其他节点持有的热点块（如序列、状态表）。
- 先确认是否真有倾斜：用
SELECT inst_id, SUM(blocks_received) r, SUM(blocks_served) s FROM gv$sysstat WHERE name IN ('gc blocks received', 'gc blocks served') GROUP BY inst_id手动核对 - 若倾斜存在，再查
GV$SERVICE_STATS看各 service 的CONNECTIONS分布，而非直接怀疑网络带宽 - 单纯加大私网带宽不能解决倾斜问题；必须配合应用层负载均衡或业务逻辑改造（如拆分热点块）
OS 层 netstat -s 必须验证 reasm fails 是否上涨
AWR 的 RAC 统计只是结果，真因得下 OS 查。重点跑：netstat -s | grep -i "reasm\|frag\|drop"，盯紧 IpReasmFails —— 这个值只要持续非零增长，99% 就是 MTU 不匹配（比如一端设了 9000，交换机或对端还卡在 1500）。它比 ping 测试更准，因为反映的是真实 GC UDP 流量的分片失败情况，不是 ICMP。
很多团队改完 ip link set dev eth1 mtu 9000 就以为搞定，结果 IpReasmFails 照涨。根本原因是没停集群统一配，或交换机端口没开 jumbo frame，或网卡驱动不支持（ethtool eth1 显示 Supports jumbo frames: No）。
- 必须所有节点、所有中间交换机、所有网卡驱动，端到端一致支持 9000 MTU，缺一不可
- 改完 MTU 后，重启 CRS（
crsctl stop crs && crsctl start crs），否则 LMS 进程仍读旧值 - 抓包验证：用
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u，看到大量 8972 字节帧才算真正走通巨帧
IpReasmFails 这一行输出。它不报错，不中断，但每秒几个失败，累积起来就让 GC 等待翻倍。别等节点驱逐才动手。
