面试宝典: Oracle数据库gc cr block 2-way等待事件处理过程

🔍 Oracle 数据库 gc cr block 2-way 等待事件详解

gc cr block 2-way 是 Oracle RAC（Real Application Clusters） 环境中与一致性读块（CR Block）跨实例传输直接相关的等待事件，表示CR块通过两个节点直接交互完成传输（无需磁盘读）。以下是深度解析：

---

⚙️ 一、产生机制与核心原理

1. 缓存融合（Cache Fusion）中的CR块传输

• CR块（Consistent Read Block）：为满足查询一致性构造的历史版本块。
• 传输路径：
  • 2-way：请求实例（A）←→ 持有实例（B）
    （直接内存传输，无磁盘I/O）
  • 3-way：请求实例（A）←→ 持有实例（B）←→ 磁盘
    （需从磁盘读取UNDO构造）

2. gc cr block 2-way 触发条件

1. 实例A 需要块X的一致性读版本
2. 实例B 满足以下条件：
   • 持有块X的当前版本（XCUR） 或 PI（Past Image）
   • 拥有足够UNDO信息在内存中构造CR块
3. 实例B直接构造CR块并传输至实例A
4. 实例A等待传输完成，记录为 gc cr block 2-way

graph LR
    A[实例A：发起CR块请求] --> B[GCS定位持有者实例B]
    B --> C{实例B能否内存构造CR？}
    C -->|是| D[实例B构造CR块]
    D --> E[通过Interconnect传输]
    E --> F[实例A等待 gc cr block 2-way]
    C -->|否| G[触发3-way传输]

---

🔥 **二、典型场景与根本原因

场景	原因描述	典型案例
跨实例高频查询	多实例同时查询相同数据块，触发CR块传输风暴	全局报表并发查询
DML与查询冲突	实例B修改块后，实例A需构造CR版本	OLTP系统读写分离架构
索引范围扫描热点	多实例扫描同一索引区间，反复请求相邻叶块	日期范围查询的索引分区
UNDO保留不足	实例B的UNDO信息过早覆盖，无法构造CR块（退化为3-way）	长查询遭遇高频DML
Interconnect延迟	网络传输慢导致CR块交付延迟	未启用RDMA/巨帧
缓存争用	实例B的Buffer Cache繁忙，延迟构造CR块	高并发DML消耗CPU
Oracle Bug	CR块构造逻辑缺陷（如Bug 18456637）	11.2.0.3已知问题

---

🔍 **三、详细排查流程

✅ 步骤1：确认等待事件影响

• AWR报告分析：

  SELECT inst_id, event, total_waits, time_waited_micro
  FROM gv$system_event 
  WHERE event = 'gc cr block 2-way'
  ORDER BY time_waited_micro DESC;
  

• 实时会话定位：

  SELECT inst_id, sid, serial#, sql_id, event, p1, p2, p3 
  FROM gv$session 
  WHERE event = 'gc cr block 2-way';
  

✅ 步骤2：定位热点对象与块

• 解析参数：
  • P1 = file_id（文件号）
  • P2 = block_id（块号）
• 对象定位：

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

✅ 步骤3：分析CR块构造能力

• 检查UNDO保留时间：

  -- 确认UNDO表空间保留策略
  SELECT tablespace_name, retention 
  FROM dba_tablespaces 
  WHERE contents = 'UNDO';
  
  -- 查看活跃UNDO使用量
  SELECT inst_id, ROUND(SUM(used_ublk)*8/1024 "Active UNDO (MB)"
  FROM gv$transaction 
  GROUP BY inst_id;
  

✅ 步骤4：追踪CR块传输路径

• 对比2-way与3-way比例：

  SELECT name, value 
  FROM gv$sysstat 
  WHERE name IN (
      'gc cr blocks received',         -- 总CR块接收
      'gc cr blocks served',           -- 总CR块提供
      'gc current blocks served'       -- 当前块提供
  );
  

  健康指标：
  gc cr blocks served / gc cr blocks received > 90% （2-way占主导）

✅ 步骤5：诊断网络与缓存性能

• Interconnect延迟检测：

  SELECT * FROM gv$cluster_interconnects;
  

• Buffer Cache效率：

  SELECT inst_id, name block_type, 
         ROUND((1 - (physical_reads / (db_block_gets + consistent_gets)) * 100, 2) "Hit Ratio (%)"
  FROM gv$buffer_pool_statistics;
  

---

🛠️ 四、解决方案与优化实践

1. 减少跨实例CR请求

• 应用分区亲和性：

  -- 按实例路由查询（应用层实现）
  -- 示例：实例1处理用户ID尾号0-4，实例2处理5-9
  

• 结果集缓存：

  SELECT /*+ RESULT_CACHE */ product_id, SUM(qty) 
  FROM sales GROUP BY product_id;
  

2. 优化UNDO管理

• 延长UNDO保留：

  ALTER TABLESPACE undotbs1 RETENTION GUARANTEE; 
  ALTER SYSTEM SET undo_retention=3600;  -- 单位：秒
  

• 扩容UNDO表空间：

  ALTER TABLESPACE undotbs1 ADD DATAFILE '+DATA' SIZE 20G;
  

3. 热点块治理

• 反向键索引：

  CREATE INDEX sales_idx ON sales(order_id) REVERSE;
  

• 哈希分区：

  CREATE TABLE orders (...) PARTITION BY HASH(customer_id) PARTITIONS 16;
  

4. Interconnect优化

• 启用巨帧（Jumbo Frames）：

  # Linux配置
  ifconfig eth1 mtu 9000
  

• 绑定网络进程：

  # 设置UDP缓冲区大小
  sysctl -w net.core.rmem_max=16777216
  sysctl -w net.core.wmem_max=16777216
  

5. 参数调优

-- 增加CR块保留时间（默认600秒）
ALTER SYSTEM SET "_gc_cr_time"=1800 SCOPE=spfile; 

-- 提升CR构造优先级
ALTER SYSTEM SET "_gc_cr_priority"=1 SCOPE=spfile;  -- 0:公平 1:优先CR

-- 增加Buffer Cache（减少磁盘回退）
ALTER SYSTEM SET db_cache_size=20G SCOPE=spfile;

6. Bug修复

# 应用CR块构造补丁（示例）
opatch apply -id 18456637

---

💎 五、深度优化建议

1. CR热点块监控脚本：

   SELECT file_id, block_id, COUNT(*) AS cr_requests,
          AVG(time_waited) AS avg_wait_ms
   FROM gv$active_session_history
   WHERE event = 'gc cr block 2-way'
   GROUP BY file_id, block_id
   ORDER BY cr_requests DESC
   FETCH FIRST 10 ROWS ONLY;
   

2. 预防性维护策略：

   • 每周检查2-way传输比例：

     SELECT (SUM(CASE name WHEN 'gc cr blocks served' THEN value END) / 
             SUM(CASE name WHEN 'gc cr blocks received' THEN value END)) * 100 "2-way Ratio (%)"
     FROM gv$sysstat;
     

   • 月度重组高频扫描表

---

📌 总结

gc cr block 2-way 的本质是 RAC环境下高效内存传输CR块的协作过程，核心优化方向：
✅ 减少跨实例请求（分区亲和+结果集缓存）
✅ 保障UNDO可用性（延长保留+空间扩容）
✅ 消除热点块（反向键索引+哈希分区）
✅ 加速网络传输（巨帧+缓冲区优化）
通过监控 gv$sysstat 传输比例、gv$active_session_history 热点块及网络指标，可精准提升CR块交互效率，显著降低全局查询延迟。

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