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

原创于 2025-08-06 21:16:01 发布 · 1k 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述

🔍 Oracle 数据库 `gc cr block busy` 等待事件详解

gc cr block busy 是 Oracle RAC（Real Application Clusters） 环境中与一致性读块（CR Block）传输阻塞相关的关键等待事件，表示请求实例在接收CR块时因资源繁忙被延迟。以下是深度解析：

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

1. 缓存融合中的CR块传输流程

实例A 请求块X的一致性读版本（CR Block）
GCS 定位持有该块的 主实例（Master Instance）B
实例B 在内存中构造CR块
实例B 通过Interconnect发送CR块
实例A 接收并缓存该块

2. `gc cr block busy` 触发点

当 步骤4→5 出现以下任一阻塞时触发：

📦 接收缓冲区繁忙：实例A的Buffer Cache无法立即分配空间
⚡ 资源争用：实例A的Cache Buffers Chain（CBC）锁冲突
🚦 GCS协调延迟：全局资源状态同步超时

在这里插入图片描述

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

场景	原因描述	典型案例
高频跨实例查询	多实例同时请求相同CR块，接收端缓冲区竞争	全局报表并发查询
热点索引扫描	多实例反复扫描同一索引叶块，触发密集CR请求	日期字段索引范围查询
Buffer Cache过小	接收实例缓存不足，频繁触发空间分配争用	SGA配置不合理
CBC Latch争用	接收端Cache Buffers Chain锁冲突（如_hash_latches不足）	高并发DML与查询混合负载
Interconnect性能瓶颈	网络延迟导致CR块积压，接收队列拥塞	未启用RDMA/巨帧
GCS进程过载	LMS进程CPU饱和，延迟处理CR块传输请求	CPU资源不足的节点
Oracle Bug	CR块处理逻辑缺陷（如Bug 16472715）	11.2.0.4常见问题

🔍 **三、详细排查流程

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

-- 集群级等待统计
SELECT inst_id, event, total_waits, time_waited_micro
FROM gv$system_event 
WHERE event = 'gc cr block busy'
ORDER BY time_waited_micro DESC;

-- 实时阻塞会话
SELECT inst_id, sid, serial#, sql_id, event, p1, p2, p3, blocking_session
FROM gv$session 
WHERE event = 'gc cr block busy';

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

/* 解析P1/P2参数 */
SELECT 
  &P1 AS file_id, 
  &P2 AS block_id,
  DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(&P3) AS master_file_id,
  DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(&P3) AS master_block_id
FROM dual;

-- 定位对象
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;

✅ 步骤3：诊断接收端资源争用

-- 1. CBC Latch争用检查
SELECT child#, gets, misses, sleeps
FROM v$latch_children 
WHERE name = 'cache buffers chains'
ORDER BY misses DESC;

-- 2. Buffer Cache压力
SELECT inst_id, name, 
       free_buffer_wait, buffer_busy_wait
FROM gv$buffer_pool_statistics;

-- 3. 接收缓冲区状态
SELECT * FROM v$cr_block_server;  -- 关注BUSY列

✅ 步骤4：分析CR块来源与传输

-- 1. 主实例CR服务能力
SELECT inst_id, CR_BLOCKS_SERVED, BUSY_PERCENT 
FROM gv$cr_block_server;

-- 2. 网络传输效率
SELECT inst_id, name, value
FROM gv$sysstat
WHERE name LIKE '%gc cr%' 
   OR name LIKE '%interconnect%';

-- 3. GCS进程负载
SELECT inst_id, process, status, busy_rate 
FROM gv$ges_process 
WHERE process LIKE 'LMS%';

✅ **步骤5：溯源SQL与工作负载

-- 关联问题SQL
SELECT sql_id, sql_text 
FROM gv$sql 
WHERE sql_id IN (
    SELECT sql_id FROM gv$session 
    WHERE event = 'gc cr block busy'
);

-- 热点对象访问模式
SELECT inst_id, object_name, 
       SUM(CR_BLOCKS_SERVED) AS cr_served
FROM gv$cr_block_server 
JOIN dba_objects ON (object_id = CURRENT_OBJ)
GROUP BY inst_id, object_name;

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

1. 减少CR块传输需求

本地化查询路由：

-- 应用层按分区路由（示例）
-- 实例1处理分区P1，实例2处理分区P2

结果集缓存：

SELECT /*+ RESULT_CACHE */ ... FROM sales WHERE region='EAST';

2. 优化接收端资源

增加Buffer Cache：

ALTER SYSTEM SET db_cache_size=30G SCOPE=spfile;

扩展_hash_latches：

ALTER SYSTEM SET "_db_block_hash_latches"=8192 SCOPE=spfile;

缓解CBC Latch争用：

ALTER SYSTEM SET "_db_block_hash_buckets"=1048576 SCOPE=spfile;  -- 需重启

3. 提升CR服务能力

增加LMS进程：

ALTER SYSTEM SET gcs_server_processes=8 SCOPE=spfile;

绑定LMS到专用核：

# Linux示例
taskset -pc 8-11 ora_lms0

4. 网络层优化

# 启用巨帧（所有RAC节点）
ifconfig eth1 mtu 9000

# 调整UDP缓冲区
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

5. 对象级优化

反向键索引：

CREATE INDEX sales_idx ON sales(order_id) REVERSE;

压缩低频更新表：
```
ALTER TABLE sales COMPRESS FOR OLTP;
```

6. 参数调优

-- 提升CR块处理优先级
ALTER SYSTEM SET "_gc_cr_priority"=1 SCOPE=spfile; 

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

7. Bug修复

# 应用CR块处理补丁
opatch apply -id 16472715

💎 五、深度优化建议

1. 实时监控脚本

-- CR阻塞热点对象监控
SELECT ash.inst_id, obj.owner, obj.object_name, 
       COUNT(*) AS busy_waits,
       ROUND(AVG(ash.wait_time)/1000) AS avg_wait_ms
FROM gv$active_session_history ash
JOIN dba_objects obj 
  ON (ash.current_obj# = obj.object_id)
WHERE ash.event = 'gc cr block busy'
  AND ash.sample_time > SYSDATE - 15/1440  -- 近15分钟
GROUP BY ash.inst_id, obj.owner, obj.object_name
ORDER BY busy_waits DESC;

2. 预防性维护策略

每日检查：

SELECT * FROM v$cr_block_server WHERE busy > 20;  -- BUSY>20%需关注

月度健康检查：

-- CBC Latch效率
SELECT (1-(misses/(gets+0.001)))*100 "Hit Ratio (%)"
FROM v$latch WHERE name='cache buffers chains';

📌 总结

gc cr block busy 的本质是 CR块接收端的资源协调瓶颈，核心优化方向：
✅ 减少跨实例CR请求（查询本地化+结果缓存）
✅ 消除接收端争用（扩容Buffer Cache+优化CBC Latch）
✅ 提升CR服务能力（增加LMS+CPU绑定）
✅ 加速网络传输（巨帧+缓冲区优化）
通过联合分析 v$cr_block_server、v$latch_children 及ASH数据，可精准定位阻塞点，显著提升RAC集群的CR块处理效率。