面试宝典: Oracle数据库 gc cr block lost 等待事件处理过程

以下是关于Oracle数据库中gc cr block lost等待事件的详细介绍，包括产生过程、常见场景、可能原因及详细排查流程：

---

一、等待事件定义与背景

gc cr block lost是Oracle RAC（Real Application Clusters）环境中特有的等待事件，表示节点间请求的一致性读（CR）数据块在私有网络传输过程中丢失。该事件通常与gc current block lost（当前块丢失）同时出现，直接反映私有网络（interconnect）的通信异常。

---

二、产生过程与机制

1. 数据块请求阶段：

   • 实例A需要访问的数据块在实例B的缓存中。
   • 实例A向实例B发送gc cr request请求该数据块的CR副本。

2. 数据传输阶段：

   • 实例B通过私有网络（UDP协议）将数据块分片打包发送。
   • 数据包需在接收端（实例A）重组为完整数据块。

3. 丢失触发条件：

   • 数据包在传输中丢失、校验失败或重组超时。
   • 实例A未能在30毫秒内收到完整数据块，标记为gc cr block lost，并重新发起请求。

---

三、常见场景与症状

1. 性能表现：

   • SQL执行缓慢，尤其涉及多表关联的全表扫描（伴随gc cr multiblock requests等待）。
   • AWR报告中gc cr block lost位列Top 5等待事件，平均等待时间 > 100ms（正常应 < 1ms）。

2. 系统级症状：

   • netstat -s显示UDP错误：packet receive errors、fragments dropped after timeout。
   • 操作系统层面网络丢包（ifconfig中RX errors/TX errors激增）。
   • CPU使用率异常升高（内核协议栈处理重传）。

---

四、根本原因分类

1. 硬件层问题（占比>40%）

• 网卡/光纤故障：光模块衰减（案例：节点光衰过大导致丢包）。
• 交换机配置错误：端口双工模式不匹配、MTU不一致、流控（Flow-control）未开启。
• 线缆质量差：非CAT5以上标准线缆或端口接触不良。

2. 操作系统配置问题（占比>30%）

• UDP缓冲区过小：
  • Oracle默认使用128KB缓冲区，若DB_FILE_MULTIBLOCK_READ_COUNT较大（如>4），需调大OS参数。
  • 检查命令：netstat -su 查看 udpInOverflows 或 packets dropped due to buffer full。
• 数据包重组失败：
  • 高CPU负载导致重组超时（fragments dropped after timeout）。
  • 关键参数：ipfrag_low_thresh（默认196KB）、ipfrag_high_thresh（默认262KB）过小。

3. 网络协议与参数（占比>20%）

• MTU不匹配：私有网络设备MTU未统一（建议Jumbo Frames=9000）。
• UDP校验和错误：网卡Checksum Offloading功能缺陷（需关闭：ethtool -K eth1 rx off tx off）。

4. 其他原因

• 防火墙过滤RAC心跳包。
• 网卡驱动BUG或固件过时。

---

五、详细排查流程

1. 确认症状

• AWR报告：检查Global Cache Load Profile，关注gc cr block lost次数及延迟。
• SQL追踪：查找反复出现gc cr request的SQL（通常涉及多块读）。

2. 操作系统层检查

• 网络错误统计：

  netstat -su | grep "packet receive errors\|fragments dropped after timeout"  # 
  ifconfig | grep "RX errors\|TX errors"
  

• MTU一致性验证：

  ping -s 8972 <节点IP>  # （MTU=9000时测试，若不通则存在MTU问题）
  

3. 关键参数检查

• UDP缓冲区设置（Linux示例）：

  sysctl net.core.rmem_max  # 应 ≥ 20971520（20MB）
  

• 重组缓冲区与超时（Linux调优）：

  sysctl -w net.ipv4.ipfrag_high_thresh=41943040    # 增大重组缓冲区
  sysctl -w net.ipv4.ipfrag_time=120                # 延长重组超时
  

4. 硬件诊断

• 光衰检测（光纤环境）：

  ethtool -m eth1 | grep "Laser output power"  # 正常值：-7~2dBm，超出范围需更换光模块。
  

• 交换机日志：检查端口CRC错误、丢包计数。

5. 负载测试与切换

• 网卡绑定切换（AIX示例）：

  smitty etherchannel → Force Failover  # 切换到备用网卡。
  

• 降低多块读：临时调整DB_FILE_MULTIBLOCK_READ_COUNT，观察是否缓解。

---

六、典型案例

1. 光模块衰耗
   现象：某银行跑批作业从2分钟延至30分钟。
   排查：netstat -s显示fragments dropped after timeout激增，检测主网卡光衰超标。
   解决：切换至备用网卡后恢复。

2. 重组缓冲区不足
   现象：RAC节点频繁驱逐（eviction）。
   排查：netstat -s报告packet reassembles failed。
   解决：调整ipfrag_high_thresh=40MB、ipfrag_time=120秒后正常。

---

七、预防措施

• 网络层：使用专用交换机隔离RAC心跳流量，启用Jumbo Frames并统一MTU。
• OS层：
  • 设置rmem_max/wmem_max=20MB（Linux）。
  • 监控/proc/net/snmp中的UdpInErrors。
• 数据库层：定期检查AWR的Global Cache Efficiency（目标>98%）。

⚠️ 注意：若调整后仍出现丢包，需捕获网络包分析（tcpdump）并联合网络团队排查硬件。

通过以上步骤，可系统性定位并解决gc cr block lost问题，本质是私有网络的稳定性与配置优化。

欢迎关注我的公众号《IT小Chen》