结论是私网UDP丢包所致，需优先检查OS网络栈：ifconfig查dropped、netstat -su看UdpInOverflows、ethtool -S查rx_discards/rx_pause_cnt，三者顺序不可颠倒，因底层丢包会掩盖上层现象。
直接结论：不是数据库配置或sql问题，90%以上是私网udp丢包导致的，必须从os网络栈查起。
gc current block lost 真实含义不是“块丢了”，而是“没收到响应”
Oracle 11g RAC用UDP发CURRENT块，接收端超时（默认30ms）或校验失败就记为gc current block lost。它不表示存储损坏，而是网络层传输失败的最终体现——和TCP重传、UDP socket溢出、驱动丢包强相关。
常见误判点：
- 看到等待时间500ms就去调
_gc_read_mostly_latches或gc_files_to_locks，白忙活 - 只查
GV$SYSTEM_EVENT却不看netstat -su，漏掉UdpInOverflows这个关键指标 - 认为ifconfig里RX/TX正常=网络没问题，但
dropped字段可能已悄然上涨
必须立刻检查的三个OS级丢包点
顺序不能乱，因为底层丢包会掩盖上层现象：
-
ifconfig bond1 | grep -E "(dropped|errors)"：持续增长说明驱动层已开始丢包。重点盯dropped（ring buffer满、DMA失败），不是“应用没收到”而是网卡自己拒收 -
netstat -su | grep UdpInOverflows：值非零=内核UDP接收队列溢出，gc current block lost必然飙升。根源常是net.core.rmem_max太小（建议≥24MB） -
ethtool -S bond1 | grep -i discard：查rx_discards（微码过滤）、rx_pause_cnt（交换机流控触发丢包）。这两个值高，说明问题在硬件或交换机，不是Oracle能调的
为什么重负载下才暴露？因为UDP流量是突发的
RAC私网流量天生bursty：一个SQL扫描多块→瞬间触发几十个GC请求→UDP包扎堆抵达→接收缓冲区瞬间打满→UdpInOverflows跳涨→gc current block lost爆发。
此时容易踩的坑：
- 用
ping -c 100 <priv_ip></priv_ip>测延迟，但RAC要求95%包≤2ms，而普通ping不反映UDP burst压力 - 只看单节点
ifconfig，忽略bonding底层物理口（如ens2f0/ens2f1）各自的rx_crc_errors，真实故障点可能藏在其中一块 - 改完
sysctl参数后没执行sysctl -p，或Oracle进程是参数生效前启动的，新连接仍用旧缓冲区
AWR里最该盯的两个数字，不是Top 5等待
别被gc current block lost排进Top 5就慌，先翻AWR报告里的这两处：
-
Avg global cache block receive time (ms)：超过10ms基本确认私网延迟，11g默认超时就是30ms，再叠加重传就到500ms -
Estd Interconnect traffic (KB)：平时几百KB/s，突增至几MB/s（比如24 MB/s），说明Cache Fusion流量暴增，大概率是MTU不匹配或丢包引发重传堆积
这两个值异常，再结合ocssd.log里是否密集出现CRS-1611（丢失75%心跳），就能锁定是网络抖动而非单点故障。
