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

以下是关于Oracle RAC中 gc cr grant busy 等待事件的全面解析，涵盖其机制、触发场景、根因及系统化排查流程：

---

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

定义：当实例请求一个一致性读（CR）块时，资源主节点（Master Instance）因资源繁忙无法立即响应授权请求而产生的等待。与gc cr grant 2-way的区别在于：

• grant busy：主节点因处理能力不足延迟响应
• grant 2-way：主节点授权磁盘读取（无缓存块）

关键流程：

1. 请求发起：实例A向主节点（如实例B）发送gc cr request
2. 主节点阻塞：主节点的LMS进程因以下原因无法及时处理请求：
   • CPU资源争用（LMS进程调度延迟）
   • 全局资源锁冲突（如gc element争用）
   • 消息队列积压（ges message queue）
3. 等待标记：实例A在未获响应期间记录gc cr grant busy等待

---

⚠️ 二、典型触发场景

场景类型	具体表现	关联事件
LMS进程过载	单节点CPU使用率>90%，LMS进程占CPU 50%+	latch: ges resource hash
热点资源争用	高频访问同一数据块（如全表扫描热点段）	gc buffer busy
DRM动态重配	动态资源管理（DRM）迁移资源时主节点切换	gc drm freeze in enter
网络消息积压	UDP缓冲区溢出导致授权消息延迟	gc lost blocks

---

🔍 三、根本原因分类

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

• CPU饱和：GCS_SERVER_PROCESSES数量不足或未绑定实时优先级（RT）
• 调度延迟：操作系统未配置LMS进程为实时调度（Linux需chrt -r）
• 进程挂起：LMS被阻塞在ges相关闩锁（latch: ges resource hash list）

2. 全局资源争用（~25%）

• 热点对象：高频DML操作导致gc current grant busy连带触发CR授权阻塞
• DRM资源冻结：动态重配期间主节点暂停处理请求（drm freeze）

3. 网络与队列问题（~10%）

• UDP缓冲区溢出：netstat -su显示packet receive errors
• GES消息积压：gv$ges_blocking_enqueue中REQ_REASON=busy

4. 参数配置不当（~5%）

• _gc_affinity_time 过短导致DRM频繁触发
• _lm_send_buffers 不足影响消息传递

---

🧩 四、详细排查流程

1. 症状定位

• AWR报告分析：

  SELECT event, total_waits, time_waited_micro/1000 "Time(ms)", wait_class
  FROM dba_hist_system_event  
  WHERE event LIKE 'gc cr grant busy%';  -- 确认等待时间占比
  

• ASH实时追踪：

  SELECT inst_id, sql_id, current_obj#, COUNT(*)  
  FROM gv$active_session_history  
  WHERE event = 'gc cr grant busy'  
  GROUP BY inst_id, sql_id, current_obj#;  -- 定位热点对象与SQL
  

2. LMS进程诊断

• CPU与调度检查（Linux）：

  ps -eLo pid,cls,rtprio,pri,nice,cmd | grep lms  # 确认调度策略（RT应为1）
  top -p $(pgrep -f lms)  # 实时监控LMS CPU使用
  

• LMS阻塞分析：

  SELECT sid, event, p1, p2, p3 
  FROM gv$session 
  WHERE program LIKE '%LMS%';  -- 检查LMS阻塞事件
  

3. 资源争用分析

• 热点资源定位：

  SELECT * FROM (  
    SELECT file#, block#, COUNT(*) cnt  
    FROM gv$ges_blocking_enqueue  
    WHERE req_reason='busy'  
    GROUP BY file#, block#  
    ORDER BY cnt DESC  
  ) WHERE ROWNUM <= 5;  -- 排名前5的热点块
  

• DRM活动监控：

  SELECT * FROM gv$gc_drm_info;  -- 检查DRM迁移状态
  
  

4. 网络与队列检查

• UDP缓冲区诊断：

  netstat -su | grep -E "packet receive errors|packets to unknown port"  
  sysctl net.core.rmem_max  # 应≥20MB（Jumbo Frames环境）
  

• GES消息积压：

  SELECT inst_id, SUM(kjblmsize) "Queue Size (KB)"  
  FROM x$kjbl  
  GROUP BY inst_id;  -- 正常值<100KB/节点
  

---

🛠️ 五、优化解决方案

1. 紧急缓解措施

• LMS进程调优：

  ALTER SYSTEM SET GCS_SERVER_PROCESSES=4 SCOPE=BOTH;  -- 按CPU核数增加（每32核1个LMS）
  

  chrt -r -p 99 <LMS_PID>  # Linux设置实时优先级
  

• 热点资源分散：

  ALTER TABLE table_name INITIAL 2m NEXT 2m PCTFREE 40;  -- 增大数据块密度降低争用
  

2. 参数调优

ALTER SYSTEM SET "_gc_affinity_time"=300 SCOPE=SPFILE;  -- 延长DRM决策周期  
ALTER SYSTEM SET "_lm_send_buffers"=16384 SCOPE=SPFILE; -- 增大GES消息缓冲区  

3. 架构级优化

• 分区隔离：

  CREATE TABLE sales PARTITION BY HASH(sale_id) PARTITIONS 4;  
  ALTER TABLE sales MODIFY PARTITION p1 MASTER AT SITE rac1;  -- 绑定分区到指定实例
  

• 缓存预热：

  EXEC dbms_prefetch.prefetch_objects('TABLE', 'SCHEMA.TABLE');  -- 预加载热表
  

4. 网络层加固

# Linux Jumbo Frames配置示例
ifconfig eth1 mtu 9000  
sysctl -w net.core.rmem_max=20971520  
sysctl -w net.core.wmem_max=20971520  

---

💎 六、典型案例

案例1：LMS优先级丢失导致集群瘫痪

现象：AIX系统升级后，gc cr grant busy激增，节点频繁驱逐（eviction）。
根因：新内核未继承LMS实时优先级（PRI<40）。
解决：

schedo -p -o sched_rt_priority=40 -c <LMS_PID>  # AIX重置实时优先级

案例2：DRM频繁触发引发授权阻塞

现象：每小时固定出现gc cr grant busy高峰。
根因：_gc_affinity_time=10导致DRM每10分钟评估资源迁移。
解决：

ALTER SYSTEM SET "_gc_affinity_time"=720 SCOPE=SPFILE; -- 延长至12小时

---

📊 总结

gc cr grant busy本质是主节点处理能力不足的连锁反应，需分层突破：

1. 优先级检查：确保LMS运行在实时调度策略（RT/实时优先级）
2. 资源解耦：通过分区/缓存预热分散热点块访问
3. DRM调谐：延长_gc_affinity_time减少迁移频率
4. 网络加固：UDP缓冲区≥20MB + Jumbo Frames统一MTU

⚠️ 终极建议：若优化后仍持续高等待，需捕获 LMS进程堆栈（oradebug dump lms_dump 3）分析内核阻塞点。

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