Avg global cache block receive time 超过 100ms 需立即排查私网，该值反映真实网络层耗时；AWR 中位于“Global Cache and Enqueue Services”模块，正常应95%低于5ms；gc cr/current block lost 才是私网问题真因，本质为UDP丢包或超时，而非块丢失。
Avg global cache block receive time 超过 100ms 就该立刻停下手头所有优化，先查私网——它不是“平均等待”，而是真实网络层耗时，直接暴露心跳链路质量。
看 AWR 里 Avg global cache block receive time 是否超标
这个值在 AWR 报告末尾的 “Global Cache and Enqueue Services” 模块下，字段名就是 Avg global cache block receive time (ms)。正常应
注意它和 gc buffer busy acquire 的区别：gc buffer busy acquire 是争抢结果，而 Avg global cache block receive time 才是根因信号。别被后者高占比带偏方向。
- 若该值在多个连续快照中缓慢爬升（比如从 8ms → 24ms → 64ms），大概率是温水煮青蛙式恶化，常伴随
netstat -s中IpReasmFails持续增长 - 单次采样值偶尔飙到 200ms+，需结合
dba_hist_active_sess_history查具体会话的p2text='file#'，确认是否热点块集中引发重传堆积 - 该指标对 MTU 不匹配、UDP 丢包、网卡 CRC 错误极其敏感，但对业务 SQL 变更不敏感——所以一旦异常，优先排查 OS 层
查 Estd Interconnect traffic 是否同步飙升
在同一个 AWR 报告的 “RAC Statistics” 页面找 Estd Interconnect traffic (KB)。OLTP 系统平时几百 KB/s 属正常；若突增至几 MB/s（如 24 MB/s），且与 Avg global cache block receive time 升高同步出现，大概率是 MTU 不匹配或 UDP 丢包引发重传堆积。
别只盯着带宽利用率——ethtool eth2 显示 “Link detected” 不代表无抖动，得看实际收发包质量。
- 流量没涨但延迟涨了 → 链路质量差（CRC error、交换机端口偶发丢包）
- 流量暴涨 + 延迟暴涨 → 端到端巨帧未生效，或 UDP 接收缓冲区太小（
/proc/sys/net/core/rmem_max - 流量暴涨但延迟正常 → 可能是合法 Cache Fusion 风暴（比如大并行跨节点扫描），需用
DBA_HIST_SYSSTAT对比gc cr bytes是否同步激增
交叉验证 GV$CLUSTER_INTERCONNECT 和 ocssd.log
AWR 只告诉你“结果”，真因得下操作系统查。立刻做三件事：
- 查
GV$CLUSTER_INTERCONNECT：确认ip_address走的是私网 IP，且interface列对应物理网卡（如eth3），不是lo或bond0 - 搜
ocssd.log：重点抓CRS-1611、CRS-1610、CRS-1607—— 多节点密集报这三类错误，就是底层网络抖动 - 跑
ping -c 100 -i 0.1 <对端私网IP>：RAC 要求 95% 包 ≤2ms；一旦 >5% 超 5ms，GC 等待必然上扬
避开 gc cr block 2-way 这类伪故障信号
很多 DBA 一看到 Top 5 里有 gc cr block 2-way 就调 MTU 或换网卡，其实这是正常开销。真正指向私网问题的只有两类：gc cr block lost 和 gc current block lost —— 它们本质是 IPC send timeout，不是块丢了，是 UDP 包被丢弃或延迟超限。
而 gc buffer busy acquire 平均等待 >5ms 且频次突增时，大概率是前者拖慢引发的连锁反应，别本末倒置去优化 SQL。
最狡猾的地方在于：心跳延迟不总表现为明显报错，而是让 gc cr block lost 平均等待时间缓慢爬升到 16–32ms 桶，同时 IpReasmFails 在 netstat -s 里持续增长——这种温水煮青蛙式的恶化，最容易被当成“暂时波动”忽略掉。
