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

原创于 2025-08-07 12:20:05 发布 · 1k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

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

584 篇文章

订阅专栏

在这里插入图片描述
以下是关于Oracle RAC中gc cr grant 2-way等待事件的综合分析，涵盖其机制、触发场景、根因及排查流程：

⚙️ 一、等待事件定义与机制

本质：当某个实例请求一个一致性读（CR）块，但该块不在任何实例的Buffer Cache中时，资源主节点（Master Instance）会授权请求实例直接从磁盘读取数据块。此过程产生的等待即为gc cr grant 2-way。
关键特征：
- “2-way”：仅涉及请求实例与主节点（Master Instance）的两次通信，无需第三方实例参与。
- 与物理I/O强关联：授权完成后，请求实例需执行db file sequential/scattered read从磁盘读取数据块。
- DRM影响：若动态资源管理（DRM）被禁用，频繁跨实例访问的对象可能因Master节点不匹配加剧此等待。

🔍 二、产生过程详解

本地缓存检查：实例A的进程请求数据块，先检查本地Buffer Cache是否存在该块的CR版本。
全局资源请求：若本地不存在，向该块的Master节点（如实例B）发送gc cr request。
主节点响应：Master节点检查GRD（Global Resource Directory），确认无任何实例缓存该块，随即向实例A发送grant授权信号（非数据块本身）。
磁盘读取：实例A获得授权后，从数据文件读取块，此时等待事件结束，转为物理I/O等待（如db file sequential read）。

⚠️ 三、典型触发场景

场景类型	具体表现	影响案例
对象未缓存	全表扫描或大范围索引扫描访问冷数据	跑批作业频繁读磁盘，伴随`db file scattered read`
Master节点不匹配	对象主要在实例A访问，但Master节点为实例B	跨节点请求导致授权延迟
缓存频繁刷新	Buffer Cache过小或热点对象被挤出内存	高`disk_reads`的SQL反复触发授权
SQL执行计划问题	非绑定变量导致全表扫描	非预期的大量物理读引发授权等待

🛠️ 四、根本原因分类

1. 对象与缓存问题（占比~50%）

冷数据访问：历史数据首次访问或缓存命中率低（buffer cache hit ratio < 98%）。
DRM未生效：生产环境常禁用DRM，导致Master节点与访问节点不一致。

2. SQL性能问题（占比~30%）

低效执行计划：全表扫描取代索引扫描，增加物理I/O需求。
非绑定变量：执行计划波动，偶发全表扫描。

3. LMS进程与系统资源（占比~15%）

LMS配置不足：GCS_SERVER_PROCESSES参数过小或进程未运行在实时优先级（Real Time）。
CPU/内存竞争：LMS进程因系统资源不足响应延迟。

4. 网络与参数配置（占比~5%）

UDP缓冲区不足：大数据块传输时丢包（需验证netstat -su | grep "packet receive errors"）。
次要影响：网络延迟通常非主因（授权消息仅几KB）。

🧩 五、详细排查流程

1. 症状确认

AWR报告分析：
- 检查Top 5 Timed Events中gc cr grant 2-way的等待时间及平均延迟（>1ms需关注）。
- 查看Global Cache Efficiency：若disk% > 0.5%表明缓存不足。

ASH实时追踪：

SELECT sql_id, object_id, COUNT(*) 
FROM gv$active_session_history 
WHERE event = 'gc cr grant 2-way' 
GROUP BY sql_id, object_id;  -- 定位高频SQL及对象

2. 对象与缓存诊断

识别Master节点：

SELECT KJBRMASTER, COUNT(*) 
FROM x$kjbr 
WHERE KJBRPKEY = &data_object_id;  -- 需提前查询对象的DATA_OBJECT_ID

缓存命中评估：

SELECT (1 - (phy.value / (cur.value + con.value))) * 100 "Buffer Hit Ratio"
FROM v$sysstat cur, v$sysstat con, v$sysstat phy
WHERE cur.name = 'db block gets'
  AND con.name = 'consistent gets'
  AND phy.name = 'physical reads';  -- 低于98%需扩容缓存或优化SQL

3. SQL优化

执行计划分析：

EXPLAIN PLAN FOR 
SELECT * FROM table WHERE ...;  -- 检查是否出现FULL TABLE SCAN

绑定变量强制：

EXEC dbms_shared_pool.purge('&address,&hash_value', 'C');  -- 刷新问题SQL计划

4. LMS与系统检查

LMS优先级与数量：

ps -elf | grep lms   # AIX/Linux：PRI < 40 表示实时优先级

SHOW PARAMETER gcs_server_processes;  -- 建议每32核CPU配置2个LMS

系统资源监控：

top -p $(pgrep -f lms)  # 检查LMS进程的CPU/内存占用

5. 网络层验证

UDP缓冲区设置（Linux示例）：

sysctl net.core.rmem_max  # 应≥4MB（DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT +4KB）

丢包统计：

netstat -su | grep "receive errors\|packets dropped"  -- 非零值需调优OS参数

🛡️ 六、优化解决方案

缓存预热：

高频访问表主动加载至缓存：

ALTER TABLE table_name CACHE;  
SELECT /*+ FULL(table_name) */ * FROM table_name;  -- 全表扫描预加载

人工Remastering：

在维护窗口执行：

EXEC oradebug lkdebug -m;  -- 需结合内部命令调整Master节点

SQL与对象优化：
- 为全表扫描SQL添加索引或使用绑定变量。
- 分区表按实例隔离访问（Partitioning by Instance）。
参数调优：
- 增加Buffer Cache（DB_CACHE_SIZE）。
- 确保GCS_SERVER_PROCESSES匹配CPU核心数。
启用DRM（谨慎评估）：
- 设置_gc_policy_time=10（分钟级策略调整），监控动态Master切换稳定性。

💎 七、典型案例

非绑定变量引发全表扫描
现象：跑批作业卡在gc cr grant 2-way，耗时从2分钟增至30分钟。
根因：UPDATE语句未用绑定变量，执行计划变为全表扫描。
解决：刷新问题SQL执行计划并改用绑定变量。
Master节点不匹配
现象：频繁跨实例查询表，AWR显示gc cr grant 2-way占DB Time 29%。
解决：人工Remastering将对象Master切至访问实例。
LMS进程优先级不足
现象：CPU扩容后实例间LMS数量不均衡，授权延迟>150ms。
解决：统一各节点GCS_SERVER_PROCESSES并设置实时调度。

📊 总结

gc cr grant 2-way是RAC中典型的磁盘授权等待，核心矛盾在于数据块未缓存与跨节点访问开销。优先通过对象缓存、SQL优化、DRM调优降低物理I/O需求，再辅以LMS和网络参数检查，可系统性缓解此类性能瓶颈。若调整后仍持续出现，需结合ASH与AWR深入分析对象访问模式。

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