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

以下是关于 Oracle RAC 中 gc current block congested 等待事件的深度解析，涵盖其机制、触发场景、根因及系统化排查流程：

---

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

定义：当请求实例无法从持有方获取当前模式（CURRENT）数据块时，因 LMS 进程消息队列积压 导致的阻塞等待。这是 RAC 中 LMS 资源饱和的严重信号。

关键特征：

• LMS 过载：持有方的 LMS 进程无法及时处理请求消息
• 队列深度超标：gv$ges_enqueue 中 cum_queue_time 激增
• 级联风险：可能触发节点驱逐（Eviction）

工作流程：

1. 请求发起：实例 A 向持有方实例 B 发送 gc current request
2. 入队阻塞：
   • 请求进入实例 B 的 GES 消息队列（gv$ges_enqueue）
   • LMS 进程因过载无法及时消费队列
3. 等待标记：
   • 实例 A 在超时（默认 300ms）前未获响应
   • 记录 gc current block congested
4. 重试/驱逐：
   • 重试 3 次失败后触发节点驱逐（OC4J 事件）

---

⚠️ 二、典型触发场景

场景类型	具体表现	关联事件
突发高并发 DML	秒杀活动或批量作业启动瞬间	gc current block busy
LMS 进程僵死	单个 LMS 进程 CPU 100% 或挂起	LMS process stuck
网络风暴	交换机广播风暴冲击私有网络	gc lost blocks
BUG 导致死锁	LMS 在资源锁上无限等待	ges enqueue: TX

---

🔍 三、根本原因分类

1. LMS 进程瓶颈（>70% 案例）

• CPU 饱和：top 显示 LMS 进程 CPU > 90%
• 进程僵死：LMS 阻塞在内部函数（如 kslgetl）
• 数量不足：GCS_SERVER_PROCESSES 未随 CPU 扩容调整

2. 全局锁冲突（~20%）

• 资源死锁：跨实例事务相互等待（gv$ges_blocking_enqueue）
• DRM 冻结：动态资源迁移期间锁超时

3. 系统资源枯竭（~10%）

• 内存泄漏：LMS 占用内存持续增长（pmap -x <PID>）
• Swap 触发：物理内存耗尽触发内存换页

---

🧩 四、详细排查流程

1. 紧急状态确认

• 集群健康检查：

  crsctl stat res -t -w "TYPE = ora.lms.type"  # 检查 LMS 状态
  

• 消息队列深度：

  SELECT inst_id, SUM(cum_queue_time) queue_time_ms 
  FROM gv$ges_enqueue 
  GROUP BY inst_id;  -- >500ms 为危险阈值
  

2. LMS 深度诊断

• CPU/内存分析：

  # 找出高负载 LMS
  ps -eo pid,pcpu,pmem,cmd | grep lms | sort -k2 -nr
  
  # 检查内存映射
  pmap -x <LMS_PID> | grep total  # 关注 RSS 增长
  

• 堆栈跟踪（需 Oracle Support）：

  oradebug setorapname lms
  oradebug unlimit
  oradebug dump processstate 10  # 生成跟踪文件
  

3. 全局锁分析

• 阻塞链定位：

  SELECT * FROM (
    SELECT inst_id, resource_name1, blocker, waiter, 
           TO_CHAR(request_time,'HH24:MI:SS') req_time
    FROM gv$ges_blocking_enqueue 
    ORDER BY request_time DESC
  ) WHERE ROWNUM <= 5;
  

• 死锁检测：

  SELECT * FROM gv$global_blocked_locks;  -- 11g+
  

4. 系统资源核查

• 内存压力：

  free -m  # Swap 使用 >0 即异常
  sar -B 1  # 查看 pgscand/s (页扫描率)
  

• CPU 调度：

  mpstat -P ALL 1  # 检查软中断分布
  pidstat -t -p <LMS_PID> 1  # 线程级 CPU 跟踪
  

---

🛠️ 五、优化解决方案

1. 紧急恢复措施

• LMS 进程重启：

  # 安全重启单个 LMS
  kill -9 <LMS_PID>  # 集群会自动重启进程
  

• 服务切换：

  ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;
  SHUTDOWN IMMEDIATE;  -- 单节点维护后重启
  

2. LMS 性能调优

• 增加进程数：

  ALTER SYSTEM SET GCS_SERVER_PROCESSES=4 SCOPE=SPFILE; 
  

• CPU 绑定（Linux）：

  taskset -pc 16-19 <LMS_PID>  # 绑定到专用 CPU 核
  

• 实时优先级：

  chrt -f -p 99 <LMS_PID>  # FIFO 调度策略
  

3. 参数级优化

-- 增大 LMS 消息缓冲区
ALTER SYSTEM SET "_lm_send_buffers"=16384 SCOPE=SPFILE;  

-- 禁用 DRM 防止冻结
ALTER SYSTEM SET "_gc_policy_time"=0 SCOPE=SPFILE;  

-- 减少重试超时（默认 300ms 改 100ms）
ALTER SYSTEM SET "_gc_congestion_retry_time"=100 SCOPE=SPFILE;

4. 架构级防御

• 流量控制：

  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    plan => 'RAC_EMERGENCY',
    comment => '限流保护');
  -- 限制并发 DML 数量
  

• 服务隔离：

  EXEC DBMS_SERVICE.MODIFY_SERVICE(
    service_name => 'batch_svc', 
    max_utilization_limit => 80);  -- 限制资源使用率
  

---

💎 六、典型案例

案例1：LMS 内存泄漏导致集群崩溃

现象：每 2 小时出现 congested 高峰，最终节点驱逐
根因：BUG 29890397（LMS 内存泄漏）
解决：

# 应用补丁
opatch apply 29890397

案例2：交换机广播风暴引发拥塞

现象：私有网络流量突增至 10Gbps，congested 激增
根因：网卡故障触发广播风暴
解决：

# 禁用故障网卡
ifconfig eth1 down
# 切换备网卡
crsctl modify resource ora.net1.network -attr "USR_ORA_IF=eth2"

案例3：序列缓存不足导致锁冲突

现象：高并发 INSERT 引发 LMS 队列深度超 1000
根因：CREATE SEQUENCE order_seq NOCACHE
解决：

ALTER SEQUENCE order_seq CACHE 10000;

---

📊 优化效果评估指标

1. 核心健康度：
   • gv$ges_enqueue.cum_queue_time < 50ms
   • LMS 进程 CPU < 40%
2. 集群稳定性：
   • 无 OC4J 驱逐事件
   • crsctl stat res -t 全资源 ONLINE
3. 应急能力：
   • 消息队列深度监控告警阈值 ≤ 200

⚠️ 终极防御方案：配置 LMS 过载熔断机制

-- 创建响应脚本 (lms_guard.sh)
#!/bin/bash
if [ $(ps -o pcpu= -p $1) -gt 95 ]; then
  kill -9 $1
fi

-- 部署监控
while true; do
  pgrep -f lms | xargs -n1 ./lms_guard.sh
  sleep 5
done

通过以上方案，可将 gc current block congested 控制在预警线内，保障 RAC 集群极端负载下的稳定性。

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