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

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

---

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

定义：当实例需要访问一致性读（CR）版本的数据块，但该块不在本地缓存时，向资源主节点（Master Instance）发起的全局缓存请求。这是 RAC 中最基础的跨实例块请求事件。

关键特征：

• 单块请求：每次请求仅针对一个数据块（区别于 multi block request）
• CR模式：请求一致性读版本（可能需构造 CR 快照）
• 网络敏感：延迟直接反映私有网络健康状况

工作流程：

1. 本地缓存检查：会话在实例 A 请求块 X，本地 Buffer Cache 不存在有效 CR 版本
2. 主节点定位：
   • 查询 GRD (Global Resource Directory) 确定块 X 的主节点（如实例 B）
3. 请求发送：实例 A 向实例 B 发送 gc cr request 消息
4. 响应处理：
   • 若实例 B 缓存中有 CR 版本：直接发送块内容
   • 若无缓存：授权实例 A 从磁盘读取（触发 gc cr grant）
5. 等待结束：实例 A 收到块或授权后继续操作

---

⚠️ 二、典型触发场景

场景类型	具体表现	关联事件
高频单块访问	索引范围扫描、嵌套循环连接	db file sequential read
CR 块构造延迟	长事务导致 undo 链过长	gc current block busy
热点块争用	多实例频繁读取同一数据块（如小表全扫描）	gc buffer busy acquire
主节点过载	Master 节点 LMS 进程 CPU 饱和	gc cr grant busy

---

🔍 三、根本原因分类

1. 网络层问题（~40% 案例）

• UDP 丢包：netstat -su 显示 packet receive errors > 0
• 网络延迟：ping 响应时间 > 1ms（正常应 < 0.5ms）
• MTU 不匹配：私有网络未启用 Jumbo Frames（MTU=1500 vs 9000）

2. LMS 进程瓶颈（~30%）

• CPU 过载：LMS 进程占用 CPU > 50%
• 调度延迟：未配置实时优先级（Linux 需 chrt -r）
• 进程阻塞：LMS 在 ges resource hash 闩锁上等待

3. 资源争用（~20%）

• CR 块构造慢：gv$session_wait 显示 read by other session
• 热点块冲突：gc buffer busy acquire 与 gc cr request 同时出现
• DRM 冻结：动态资源迁移期间请求暂停

4. 参数/设计缺陷（~10%）

• _gc_affinity_time 过短导致主节点频繁切换
• 非亲和性访问（表未分区或服务路由不当）

---

🧩 四、详细排查流程

1. 症状定位

• AWR 分析：

  SELECT event, total_waits, time_waited_micro/1000 "Avg Latency(ms)" 
  FROM dba_hist_system_event  
  WHERE event = 'gc cr request' 
    AND snap_id = (SELECT MAX(snap_id) FROM dba_hist_snapshot);
  -- 正常值 < 1ms，>5ms 需紧急处理
  

• ASH 热点块定位：

  SELECT obj, file#, block#, COUNT(*) 
  FROM gv$active_session_history  
  WHERE event = 'gc cr request' 
  GROUP BY obj, file#, block# 
  ORDER BY 4 DESC FETCH FIRST 10 ROWS ONLY;
  

2. 网络诊断

• 实时丢包检测（Linux）：

  watch -n 1 'netstat -su | grep -E "receive errors|packets dropped"'
  

• MTU 一致性验证：

  ping -M do -s 8972 <peer_IP>  # MTU=9000 时成功表示配置一致
  

• 网络延迟测试：

  # 节点间双向测试
  ping -c 100 <peer_IP> | grep "min/avg/max"
  

3. LMS 深度检查

• 进程状态分析：

  # Linux 实时优先级验证
  ps -eLo pid,cls,rtprio,cmd | grep lms  # RT 列应为 RR (实时策略)
  

• CPU 负载监控：

  top -b -n 1 -p $(pgrep -d, -f lms) | grep lms
  

• LMS 阻塞分析：

  SELECT sid, event, state, seconds_in_wait 
  FROM gv$session 
  WHERE program LIKE '%LMS%' 
    AND state = 'WAITING';
  

4. 资源争用溯源

• CR 构造溯源：

  SELECT /*+ ORDERED */ 
    a.sid, a.event, b.xidusn, b.ubafil, b.ubablk 
  FROM gv$session a, gv$transaction b 
  WHERE a.taddr = b.addr 
    AND a.event = 'gc cr request';
  

• 热点块关联对象：

  SELECT owner, segment_name, segment_type 
  FROM dba_extents 
  WHERE file_id = &file_id 
    AND &block_id BETWEEN block_id AND block_id + blocks - 1;
  

---

🛠️ 五、优化解决方案

1. 网络层调优

• Jumbo Frames 配置：

  # Linux 永久生效
  echo "MTU=9000" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  ifconfig eth1 mtu 9000
  

• UDP 缓冲区优化：

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

2. LMS 性能提升

• 增加进程数：

  ALTER SYSTEM SET GCS_SERVER_PROCESSES=4 SCOPE=BOTH;  # 每 32 核 CPU 配置 1 个 LMS
  

• 设置实时优先级（Linux）：

  # 修改启动脚本
  echo "chrt -r -p 99 \$(pgrep -f lms)" >> $GRID_HOME/bin/ohasd.bin
  

3. 资源争用化解

• 热点块分散：

  ALTER TABLE orders PCTFREE 40;  -- 增加块密度
  ALTER TABLE orders MINIMIZE RECORDS_PER_BLOCK;  -- 12c+ 分散行分布
  

• CR 优化：

  ALTER SYSTEM SET "_undo_autotune"=FALSE;  -- 禁用自动 undo 可能降低 CR 复杂度
  

4. 架构级优化

• 分区亲和性：

  ALTER TABLE sales MODIFY PARTITION sales_west 
    AFFINITY 'rac1' SERVICE 'svc_west';
  

• 服务路由控制：

  EXEC DBMS_SERVICE.MODIFY_SERVICE('oltp_svc', PREFERRED_INSTANCES => 'rac1,rac2');
  

---

💎 六、典型案例

案例 1：MTU 黑洞导致请求超时

现象：gc cr request 平均延迟 15ms，伴随 gc lost blocks。
根因：交换机 MTU=1500，服务器 MTU=9000，大包被静默丢弃。
解决：

# 统一 MTU 配置
switch(config)# interface GigabitEthernet0/1 
switch(config-if)# mtu 9000

案例 2：LMS 优先级丢失引发集群抖动

现象：Linux 内核升级后，gc cr request 尖峰达 500ms。
根因：新内核未继承实时优先级策略。
解决：

# 创建 systemd 服务确保优先级
[Service]
ExecStartPost=/bin/chrt -r -p 99 ${MAINPID}

案例 3：长事务阻塞 CR 构造

现象：特定时段 gc cr request 延迟骤增，ASH 显示关联 read by other session。
根因：报表事务未提交，构造 CR 需遍历超长 undo 链。
解决：

-- 终止长事务
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
-- 优化事务提交频率
BEGIN
  FOR rec IN (SELECT ...) LOOP
    ... -- 每 1000 行提交一次
    IF mod(v_counter,1000)=0 THEN COMMIT; END IF;
  END LOOP;
  COMMIT;
END;

---

📊 优化效果评估指标

1. 核心指标：
   • Avg global cache cr block receive time < 1ms
   • gc cr request 等待次数下降 > 50%
2. 网络健康：
   • netstat -su 中 receive errors = 0
   • ping 平均延迟 < 0.3ms
3. LMS 健康度：
   • CPU 使用率 < 30%
   • 无 ges resource hash 闩锁等待

⚠️ 终极方案：若优化后仍存在持续高延迟，启用 RAC 诊断工具包 捕获深层信息：

-- 生成 RAC 诊断报告
SQL> @$ORACLE_HOME/rdbms/admin/diagrac.sql  

-- 跟踪 gc 请求（需 Oracle Support 协助分析）
SQL> ALTER SYSTEM SET EVENTS 'trace[GRD.RPC][SQL:gc cr request] disk=high';

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