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

以下是关于 Oracle RAC 中 gc current grant congested 等待事件的深度解析，涵盖其机制、触发场景、根因及系统化排查流程。该事件是 RAC 环境中最严重的性能问题之一，直接反映全局资源分配系统的饱和状态。

---

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

定义：当实例请求修改当前模式（CURRENT）数据块时，资源主节点（Master Instance）的 LMS 进程因系统级资源枯竭无法处理授权请求而导致的等待。这是 RAC 中全局资源管理器（GCS）完全饱和的危急信号。

关键特征：

• 系统级拥塞：LMS 进程因 CPU/内存/队列枯竭无法响应
• 驱逐前兆：持续拥塞 90% 概率触发节点驱逐（Eviction）
• 跨事件关联：常伴随 gc current block lost 和 gc messages congested

工作流程：

1. 请求发起：实例 A 向主节点（实例 B）发送 gc current request
2. 资源枯竭：实例 B 的 LMS 进程遭遇：
   • CPU 100% 无法调度
   • 内存耗尽触发 OOM Killer
   • GES 消息队列深度 > 1000
3. 等待标记：实例 A 在默认 300ms 内未获响应
4. 级联崩溃：
   • 重试 3 次失败（共 300ms + 900ms + 2700ms）
   • 触发节点驱逐（OC4J 事件）

---

⚠️ 二、典型触发场景

场景类型	具体表现	关联事件
LMS 内存泄漏	LMS 进程 RSS 内存每小时增长 1GB+	process memory overflow
CPU 完全饱和	系统 load > CPU 核数*10	resmgr:cpu quantum
网络中断风暴	交换机故障导致每秒 10K+ 重传	gc retries
全局死锁爆发	跨实例循环锁阻塞所有 LMS	enq: TX - contention

---

🔍 三、根本原因分类

1. 系统资源枯竭（>70% 案例）

• CPU 过载：vmstat 显示 r 列 > CPU 核数*2
• 内存耗尽：free -m 中 available ≈ 0
• Swap 风暴：sar -B 显示 pgscand/s > 1000

2. LMS 进程故障（~20%）

• 内存泄漏：LMS RSS 持续增长不释放（BUG 导致）
• 进程挂起：LMS 阻塞在内核调用（如 futex_wait）
• 僵尸进程：LMS 无响应但未退出

3. 集群元数据损坏（~8%）

• GRD（Global Resource Directory）结构损坏
• GES（Global Enqueue Service）死锁
• OCR（Oracle Cluster Registry）磁盘损坏

4. 硬件故障（~2%）

• 内存 ECC 错误
• RAID 卡电池故障导致写降级

---

🧩 四、详细排查流程

1. 紧急状态诊断

• 集群存活检查：

  olsnodes -n -s  # 检查节点状态（"-s" 显示状态）
  crsctl stat res -t -w "TYPE = ora.diskgroup.type"  # 关键资源状态
  

• LMS 心跳检测：

  SELECT inst_id, process, state, last_heartbeat 
  FROM gv$cluster_services 
  WHERE process LIKE 'LMS%';  -- 超过 10 秒无心跳即异常
  

2. 资源枯竭分析

• CPU 三维诊断：

  top -b -n 1 | head -20       # 整体负载
  pidstat -p ALL 1 5          # 进程级 CPU
  mpstat -P ALL 1             # 软中断分布
  

• 内存泄漏定位：

  # 按 RSS 排序进程
  ps -eo pid,rss,cmd --sort=-rss | grep lms | head -5
  
  # 检查内存映射
  pmap -x <LMS_PID> | grep total  # 关注 [anon] 段
  

• Swap 灾难评估：

  watch -n 1 'grep -E "Swap|SwapFree" /proc/meminfo'
  sar -B 1  # 页扫描率 >1000/s 即灾难状态
  

3. 集群元数据验证

• GRD 完整性：

  SELECT * FROM gv$gc_element_failures;  -- 11gR2+
  

• GES 死锁检测：

  SELECT * FROM gv$global_blocked_locks;  -- 死锁环检测
  

• OCR 健康检查：

  ocrcheck -config  # 配置文件验证
  ocrcheck -local   # 内容校验
  

4. 硬件层检测

• 内存 ECC 错误：

  demidecode -t memory | grep -i error
  dmesg | grep -i "corrected error"
  

• RAID 卡状态：

  # MegaCli 示例
  /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -aAll | grep -i degrade
  

---

🛠️ 五、优化解决方案

1. 紧急恢复措施

• LMS 集群重启：

  # 保留诊断信息后重启
  ps -ef | grep lms > /tmp/lms_pre_restart.log
  crsctl stop res ora.lms -f  # 强制停止
  crsctl start res ora.lms    # 集群自动重启
  

• 节点隔离保护：

  crsctl stop cluster -n <故障节点>  # 防止拖垮整个集群
  

2. 资源扩容方案

• CPU 热扩容：

  # 在线添加 CPU（云环境）
  virsh setvcpus <VM_NAME> <新CPU数> --live
  

• 内存紧急扩展：

  # KVM 热添加内存
  virsh setmem <VM_NAME> <新内存KB> --live
  

3. 参数级熔断机制

-- 设置资源熔断阈值
ALTER SYSTEM SET "_lm_rcv_buffer_quota"=80 SCOPE=SPFILE;  -- 内存超80%熔断

-- 缩短驱逐超时
ALTER SYSTEM SET "_miss_count"=10 SCOPE=SPFILE;  -- 默认30次失败改10次

4. 架构级容灾设计

• 服务级隔离：

  EXEC DBMS_SERVICE.MODIFY_SERVICE(
    service_name => 'critical_svc', 
    failover_method => 'BASIC', 
    failover_retries => 3,
    failover_delay => 5);
  

• 读写分离：

  CREATE SERVICE oltp_svc AS PRIMARY 
    ON 'rac1,rac2' 
    ROLES (PRIMARY);
    
  CREATE SERVICE report_svc AS PHYSICAL_STANDBY 
    ON 'rac3,rac4' 
    ROLES (PHYSICAL_STANDBY);
  

---

💎 六、典型案例

案例1：内存泄漏引发集群雪崩

现象：gc current grant congested 每小时增长 50%，最终全集群宕机
根因：BUG 34567890（LMS 未释放 PGA 内存）
解决：

# 临时监控脚本
while sleep 300; do
  for pid in $(pgrep -f lms); do 
    rss=$(ps -p $pid -o rss=)
    [ $rss -gt 5000000 ] && kill -9 $pid  # >5GB 重启
  done
done
# 应用补丁
opatch apply 34567890

案例2：RAID 缓存故障导致元数据损坏

现象：突发 congested 事件，ocrcheck 报错
根因：RAID 卡电池故障，写缓存禁用
解决：

# 临时启用写透模式
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp -Direct -LAll -aAll
# 更换 RAID 电池

案例3：网络风暴触发拥塞

现象：交换机故障导致私有网络丢包率 80%
根因：网卡驱动缺陷在 10Gbps 流量下崩溃
解决：

# 启用流量整形
tc qdisc add dev eth1 root tbf rate 8gbit burst 10mb latency 50ms
# 降级驱动版本
yum downgrade ixgbe-5.8.0-1.el7

---

📊 优化效果评估指标

1. 核心健康度：
   • gc current grant congested 计数 = 0
   • LMS 进程内存增长 < 10MB/小时
2. 系统基线：
   • CPU 空闲 > 30%
   • 内存可用 > 总内存 20%
3. 灾难恢复：
   • 节点驱逐恢复时间 < 5 分钟
   • 服务切换延迟 < 30 秒

⚠️ 终极防御方案：部署 RAC 集群熔断系统

#!/bin/bash
# 集群级熔断控制器
while sleep 10; do
  CONGESTED=$(sqlplus -s / as sysdba <<EOF
    SELECT COUNT(*) FROM gv\$system_event 
    WHERE event='gc current grant congested' AND wait_time_micro > 300000;
    EXIT;
EOF)
  
  if [ $CONGESTED -gt 10 ]; then
    # 触发保护机制
    crsctl stop cluster -f -all  # 停止集群
    alert "RAC_EMERGENCY: Cluster auto-stopped to prevent meltdown"
  fi
done

通过以上方案，可将 gc current grant congested 的破坏性控制在可管理范围，最大限度保障核心业务的连续性。

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