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

以下是关于 Oracle RAC 中 gc current block lost 等待事件的深度解析，涵盖其机制、触发场景、根因及系统化排查流程。该事件是 RAC 环境中最严重的性能问题之一，直接反映私有网络数据块传输丢失。

---

⚙️ 一、等待事件本质与核心机制

定义：当请求实例向持有方请求当前模式（CURRENT）数据块，但该块在私有网络传输过程中丢失或校验失败，触发重传机制的等待事件。

关键特征：

• 数据完整性破坏：块内容在传输中丢失或损坏
• 重传触发：Oracle 自动重试（默认最多 3 次）
• 级联风险：连续丢失可能导致节点驱逐（Eviction）

工作流程：

1. 请求发送：实例 A 向持有方实例 B 请求块 X
2. 数据传输：实例 B 通过 UDP 发送块数据（分片传输）
3. 丢失判定：满足以下任一条件即触发事件：
   • 实例 A 在 15ms 内未收到任何数据包
   • 数据包校验失败（CRC 错误）
   • 分片重组超时（默认 30ms）
4. 重传机制：
   • 首次重试：立即发起
   • 二次重试：等待 300ms
   • 三次重试：等待 900ms
5. 驱逐触发：三次重传失败引发节点驱逐（OC4J）

---

⚠️ 二、典型触发场景

场景类型	具体表现	关联事件
网络硬件故障	网卡/光纤模块错误灯闪烁	gc cr block lost
UDP 缓冲区溢出	突发大数据传输（如 LOB 操作）	packet receive errors
MTU 不匹配	私有网络设备 MTU 配置不一致	fragments dropped
交换机流控触发	端口暂停（Pause Frames）导致丢包	TX flow control

---

🔍 三、根本原因分类

1. 硬件层故障（>50% 案例）

• 光模块衰耗：ethtool -m eth1 显示光功率超阈值（正常：-7~2 dBm）
• 网卡故障：ethtool -S eth1 显示 rx_crc_errors > 0
• 交换机端口错误：端口 CRC 错误计数持续增长

2. 操作系统配置（~30%）

• UDP 缓冲区不足：

  # Linux 检查
  sysctl net.core.rmem_max  # < 20MB 为风险
  

• 分片重组失败：

  netstat -s | grep "fragments dropped after timeout"  # >0 需调优
  

• IRQ 不均衡：网卡中断绑定单 CPU 导致软中断堆积

3. 网络协议问题（~15%）

• MTU 黑洞：交换机 MTU=1500 vs 服务器 MTU=9000
• UDP 校验和卸载冲突：网卡 Checksum Offloading 与驱动不兼容
• 流控（Flow Control）未启用：交换机与网卡配置不一致

4. Oracle 参数缺陷（~5%）

• _gc_use_adaptive_replay 未启用自适应重传
• _gc_undo_affinity 导致 undo 块跨节点传输

---

🧩 四、详细排查流程

1. 紧急症状确认

• 集群状态检查：

  olsnodes -s  # 确认节点状态
  crsctl stat res -t -w "TYPE = ora.diskgroup.type"  # 检查磁盘组在线
  

• AWR 关键指标：

  SELECT event, total_waits, time_waited_micro/1000 "Avg Latency(ms)" 
  FROM dba_hist_system_event  
  WHERE event = 'gc current block lost'
  ORDER BY snap_id DESC FETCH FIRST 1 ROW ONLY;
  -- 严重阈值：>100ms (正常应=0)
  

2. 网络层深度诊断

• 硬件错误检测：

  # 光功率检测（光纤环境）
  ethtool -m eth1 | grep "Laser output power"
  # 输出示例：-3.12 dBm (正常范围：-7~2 dBm)
  
  # 网卡错误统计
  ethtool -S eth1 | grep -E "err|drop"
  

• 操作系统网络指标：

  # UDP 丢包/错误
  netstat -su | grep -E "receive errors|packets to unknown port"
  
  # 分片重组失败
  netstat -s | grep "fragments dropped after timeout"
  
  # 软中断不均衡
  cat /proc/interrupts | grep eth1
  

• MTU 一致性验证：

  # 测试 Jumbo Frames 支持
  ping -M do -s 8972 <peer_IP> -c 10 | grep "packet loss"
  

3. 交换机诊断

# Cisco 示例（需登录交换机）
show interface GigabitEthernet1/1 | include errors
# 关键指标：
#   Input errors: 0
#   CRC: 0  
#   Giants: 0

# 检查流控状态
show interface flowcontrol | include Gi1/1
# 理想状态：Send Flow Control: ON, Receive Flow Control: ON

4. Oracle 内部跟踪

-- 启用 GC 跟踪（产生大量日志，谨慎使用）
ALTER SYSTEM SET EVENTS 'trace[GRD.RPC][SQL:gc current block lost] disk=high';

-- 检查重传统计
SELECT * FROM v$gc_retry_stats;

---

🛠️ 五、优化解决方案

1. 硬件层修复

• 光模块更换：光衰超过 -7dBm 或 +2dBm 立即更换
• 网卡固件升级：

  ethtool -i eth1 | grep firmware  # 确认版本
  # 下载厂商固件升级工具
  

• 交换机端口隔离：

  switch(config)# interface GigabitEthernet1/1
  switch(config-if)# shutdown
  switch(config-if)# no shutdown  # 端口软重置
  

2. 操作系统调优

• UDP 缓冲区优化：

  # Linux 永久生效
  echo "net.core.rmem_max = 20971520" >> /etc/sysctl.conf
  echo "net.core.rmem_default = 4194304" >> /etc/sysctl.conf
  sysctl -p
  

• 分片重组优化：

  sysctl -w net.ipv4.ipfrag_high_thresh=41943040  # 40MB
  sysctl -w net.ipv4.ipfrag_time=120              # 超时延长至120秒
  

• IRQ 负载均衡：

  # 启用多队列
  ethtool -L eth1 combined 8
  # 绑定中断到不同CPU
  for i in $(grep eth1 /proc/interrupts | awk '{print $1}' | sed 's/://'); do
    echo $(cat /sys/class/net/eth1/device/local_cpulist) > /proc/irq/$i/smp_affinity_list
  done
  

3. 网络协议加固

• 强制 Jumbo Frames：

  # 所有节点执行
  ifconfig eth1 mtu 9000
  

• 禁用 Checksum Offload：

  ethtool -K eth1 rx off tx off  # 解决校验和冲突
  

• 统一流控配置：

  ethtool -A eth1 rx on tx on    # 网卡启用流控
  switch(config-if)# flowcontrol receive on desired  # 交换机启用
  

4. Oracle 参数调优

-- 启用自适应重传（11g+）
ALTER SYSTEM SET "_gc_use_adaptive_replay"=TRUE SCOPE=SPFILE;

-- 增大重传超时阈值（默认15ms）
ALTER SYSTEM SET "_gc_block_recover_time"=30 SCOPE=SPFILE; 

-- 限制大块传输
ALTER SYSTEM SET "_db_block_max_cr_dba"=512 SCOPE=SPFILE;  -- 最大512个块

---

💎 六、典型案例

案例1：光衰超标导致生产中断

现象：gc current block lost 达 5000+/小时，最终节点驱逐
根因：主网卡光衰 -8.2dBm（低于 -7dBm 阈值）
解决：

# 切换备网卡
crsctl modify resource ora.net1.network -attr "USR_ORA_IF=eth2"
# 更换光模块

案例2：MTU 黑洞引发静默丢包

现象：全表扫描时 lost 事件激增，但 ping 测试正常
根因：服务器 MTU=9000，核心交换机 MTU=1500
解决：

# 交换机配置
switch(config)# interface range GigabitEthernet0/1-24
switch(config-if-range)# mtu 9000

案例3：UDP 缓冲区溢出

现象：批量 LOB 更新时丢包率 15%
计算：

• DB_BLOCK_SIZE=32KB
• DB_FILE_MULTIBLOCK_READ_COUNT=32
• 单次请求：32K * 32 = 1MB > 默认缓冲区 256KB
  解决：

sysctl -w net.core.rmem_max=20971520  # 20MB

---

📊 优化效果评估指标

1. 核心健康度：
   • gc current block lost 计数降为 0
   • netstat -su 中 packet receive errors = 0
2. 硬件指标：
   • 光功率：-7 dBm ≤ 值 ≤ 2 dBm
   • 交换机端口错误计数 24 小时无增长
3. 传输效率：
   • Avg global cache current block receive time < 0.5ms

⚠️ 终极防御方案：部署 网络层实时监控

# 丢包率监控脚本（每节点部署）
while true; do
  LOST=$(netstat -su | grep "packet receive errors" | awk '{print $1}')
  if [ $LOST -gt 0 ]; then
    # 触发诊断包捕获
    tcpdump -i eth1 -s 0 -w /tmp/gc_lost_$(date +%s).pcap &
    # 自动切换备网卡
    crsctl modify resource ora.net1.network -attr "USR_ORA_IF=eth2"
  fi
  sleep 10
done

通过以上措施，可根治 gc current block lost 问题，确保 RAC 跨节点数据传输的原子性与可靠性。

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