看到gc current block lost就该停掉sql优化和索引检查，它直接指向私网通信故障，本质是udp包丢失或ipc send timeout触发重传，非应用层问题；需立即检查avg global cache current block receive time（>100ms即严重）、estd interconnect traffic（突增至mb/s级）及os层ifconfig/netstat/udp_mem参数。
看到 gc current block lost 就该停掉SQL优化和索引检查
这个等待事件不是应用层问题，它直接指向私网通信故障。一旦在AWR的Top 5 Foreground Events里出现，尤其是平均等待时间超过500ms或总等待次数突增（比如单小时超1万次），说明UDP包已在传输链路中丢失或校验失败，不是块“真丢了”，而是ipc send timeout触发了重传机制。此时调优SQL、加索引、改绑定变量全无效——数据块根本没成功抵达请求节点。
gc current block lost 和 gc cr block lost 要一起看，但根因相同
两者区别只在请求模式：gc current block lost 是当前模式块（如DML修改中的块）传输失败；gc cr block lost 是一致性读块（CR块）传输失败。但底层都是UDP over private interconnect，共用同一套网络栈和缓冲区。所以：
- 若两者同时升高，基本锁定私网问题；
- 若仅gc current block lost 单独高，且伴随大量log file sync等待（如平均>300ms），要优先查redo写入延迟（比如ASM磁盘组IO卡顿）；
- 若gc cr block lost 显著高于gc current block lost，常见于OLAP类查询频繁跨节点读取，需结合db_file_multiblock_read_count和MTU配置交叉验证。
必须立刻核对AWR里的两个关键指标位置
别在Top SQL或Instance Efficiency里浪费时间。直奔这两处：
- Avg global cache current block receive time (ms)：正常应20ms已需警惕，>100ms基本确认私网延迟严重；
- Estd Interconnect traffic (KB)：平时几百KB/s属正常，若某小时突增至几MB/s（如12.7 MB/s），大概率是重传堆积导致流量暴增；
- 顺手扫一眼Global Cache Load Profile中的Blocks served和Blocks received比值：若某节点Blocks received远大于Blocks served（比如3:1），说明它正被动“拉块”，可能已是瓶颈节点，要重点查该节点私网接口状态。
OS层三件事不验证，诊断就等于没做
AWR只告诉你“丢了”，操作系统才告诉你“为什么丢”：
- ifconfig 查私网接口（如bond1或ib0）的rx errors、tx errors、overruns，只要非零就得深挖；
- netstat -s | grep -i "retransmit\|reassembly\|fragments" 看UDP重传、分片重组失败计数，增长快说明缓冲区溢出或MTU不匹配；
- cat /proc/sys/net/ipv4/udp_mem 和 /proc/sys/net/core/rmem_max 对照Oracle文档推荐值（19c通常要求rmem_max ≥ 262144），过小会直接导致gc current block lost飙升。
真实排查中，最容易被跳过的其实是udp_mem参数是否被其他进程动态覆盖，以及私网交换机端口是否启用了流控（Pause Frames）——这两项在AWR里完全无迹可寻，但却是高频根因。
