在Oracle RAC集群数据库中，如果一个实例发现需要的数据块或者其一致性读副本不在本实例的缓存里，就必须通过全局缓存服务向持有该块的实例发起请求，通过网络传输获取数据。这个过程中产生的等待，反映在等待事件上就是gc cr multi block request。当AWR报告中这个等待事件占据前列时，往往说明集群内部的数据块传输已经成为性能瓶颈，需要认真分析原因并采取针对性的优化措施。
gc cr multi block request等待事件的原理解析
要理解这个等待事件，首先要明白Oracle RAC中缓存融合（Cache Fusion）的工作机制。在RAC环境下，多个实例共享同一份磁盘数据，但每个实例有自己独立的SGA。当实例A需要读取某个数据块，而这个块正被实例B以当前模式持有，或者实例B上存在该块的较新版本时，实例A不能直接从磁盘读取，而必须通过私网向实例B请求这个块。
gc cr multi block request特指多块请求的场景。Oracle在进行多块读（比如全表扫描时一次读取db_file_multiblock_read_count个块）时，如果这批块中有部分块需要从远端实例获取，就会产生这个等待事件。与之对应的单块请求是gc cr block 2-way和gc cr block 3-way。多块请求的开销在于，一次逻辑上的多块IO可能被拆分成多次跨实例的消息交互，每个需要传输的块都要经历授权、传输、构造一致性读镜像的过程。
一致性读的构造过程也值得注意。远端实例收到请求后，需要根据自己的缓存版本和回滚信息，构造出请求方SCN对应的一致性读副本，然后再通过私网传输回去。如果块上的事务活动频繁，回滚的应用会消耗额外CPU，构造时间变长，等待时间也随之增加。因此这个等待事件偏高，通常不单纯是网络问题，还与块的访问模式密切相关。
如何诊断gc cr multi block request等待
诊断的第一步是确认等待事件的整体分布。可以从AWR报告的Top Foreground Events部分入手，观察gc cr multi-block request、gc cr grant 2-way、gc current block busy等集群相关等待的占比。如果集群相关的等待占了DB Time的相当比例，说明问题集中在缓存融合层面。
第二步是定位具体的对象和SQL。利用ASH视图可以快速找出是哪些会话、哪些SQL在等待这个事件。
-- 查询最近等待gc cr multi block request的会话及SQL SELECT sql_id, session_id, COUNT(*) AS wait_count FROM v$active_session_history WHERE event = 'gc cr multi block request' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id, session_id ORDER BY wait_count DESC; -- 定位等待涉及的对象 SELECT current_obj#, COUNT(*) AS wait_count FROM v$active_session_history WHERE event = 'gc cr multi block request' GROUP BY current_obj# ORDER BY wait_count DESC;
拿到对象号后，可以关联dba_objects确认具体是哪张表或索引。一般来说，出现这种等待的对象往往是频繁被全表扫描的大表，或者是被多个实例上的应用并发访问的热点表。
除了AWR和ASH，还可以借助几个重要的统计指标来判断问题的方向。gc cr blocks received和gc cr block receive time的比值反映了平均每个块接收的耗时，如果这个值明显高于正常水平，要重点排查私网质量。V$INSTANCE_CACHE_TRANSFER视图中记录了按数据文件统计的块传输情况，可以帮助确认跨实例传输集中在哪些文件对应的段上。
gc cr multi block request偏高的常见原因
第一类原因是应用访问模式不合理。典型场景是同一个应用模块在不同实例上同时运行，竞争相同的数据。比如双节点RAC上，两个节点的定时任务同时扫描同一张大表，造成大量跨实例的块传输。这种情况下即使网络再快，等待也不会消失，因为块的传输需求本身是结构性的。
第二类原因是低效SQL引发的大规模多块读。全表扫描和快速全索引扫描会触发多块读，如果被扫描的数据又恰好被其他实例修改过，读出来的块就需要远端构造一致性读镜像，等待时间成倍放大。通过执行计划可以确认SQL是否走了全表扫描，必要时通过索引优化或分区裁剪来减少扫描量。
第三类原因是私网性能问题。巨帧没有配置、交换机缓冲区不足、网卡协商速率不匹配、Exadata以外环境使用了普通以太网承载缓存融合流量等，都会导致块传输变慢。这种情况下通常伴随gc cr block receive time统计值的升高，可以通过操作系统层面的网络监控进一步确认。
针对性的优化方案
针对应用访问模式问题，最有效的手段是服务亲和性设计。通过定义服务，把访问同一组数据的应用连接固定到同一个实例上，让数据块尽量驻留在单个实例的缓存中，从源头上减少跨实例请求。例如把订单处理服务绑定在节点1，报表查询服务绑定在节点2。
-- 创建绑定到特定节点的服务
EXEC DBMS_SERVICE.CREATE_SERVICE( -
service_name => 'oltp_svc', -
network_name => 'oltp_svc', -
failover_method => 'BASIC', -
clb_goal => 'SHORT');
-- 让服务优先运行在实例1上
EXEC DBMS_SERVICE.MODIFY_SERVICE( -
service_name => 'oltp_svc', -
preferred_instances => 'rac1', -
available_instances => 'rac2');
针对大表扫描问题，可以考虑对表做分区，并配合分区裁剪减少每次扫描的块数量。对于需要并行处理的场景，使用Oracle自动并行和语句队列机制，避免多个实例同时对同一段数据发起大规模读取。另外，适当调整db_file_multiblock_read_count有时也能缓解单次等待的时长，但这是次要手段，关键还是减少不必要的多块读。
针对网络层面，建议确认私网使用专用的高速网络，开启巨帧（MTU设置为9000左右），保证交换机端口缓冲和链路速率匹配。在有条件的版本上部署HugePages减少内存页管理开销也有间接帮助。如果是心跳网络与缓存融合共用链路，务必拆分，避免相互干扰。
最后还要关注热点块本身。如果某个索引的叶子块被多个实例频繁交叉访问，可以考虑增大索引的PCTFREE让B树更稀疏，或者使用哈希分区索引分散热点；对于小表频繁全表扫描的情况，考虑用更大的缓存表或者把这类表保持在各实例本地缓存中，减少远端请求的频率。综合应用层面与系统层面的调整，才能真正把gc cr multi block request的等待时间降到合理水平。
gc cr multi block requestRAC等待事件Oracle性能优化修改时间：2026-09-10 13:56:42