在Oracle RAC环境中，gc cr block和gc current block等待事件是Cache Fusion活动的直接体现。当某个实例上的会话请求一个数据块，而该块的最新状态或读一致版本不在本地Buffer Cache中，需要从其他实例通过私有网络传输时，会话就会进入gc等待状态。gc cr block表示请求的是读一致性镜像，多发生在查询需要一致读数据时；gc current block表示请求的是块的当前版本，通常发生在DML需要进行行级修改或生成当前读场景下。理解这两个事件不能只看名称，还要结合p1、p2、p3参数判断具体文件号、块号和请求类型，否则容易误判为单纯网络问题。
一、等待事件的触发原理与参数含义
RAC中的Cache Fusion允许实例之间共享Buffer Cache中的块，避免将脏块写入磁盘后再由其他实例读取。当一个会话请求某个数据块时，先查找本地Buffer Cache；如果本地没有，则会向全局资源目录和锁管理服务发起请求。如果目标块由其他实例持有，Oracle会通过私有网络将块内容直接传送到请求实例。根据请求目的不同，传输的块可能是读一致性镜像，也可能是当前版本块，对应的事件分别为gc cr block和gc current block。
从参数角度看，gc cr block事件的p1通常是文件号，p2是块号，p3是请求类型。通过v$session中的p1、p2可以快速映射到具体的数据文件和块，再结合dba_extents视图定位对象。gc current block事件的p1、p2含义类似，但p3通常表示请求当前块的具体原因，例如正在进行行级修改或需要生成新快照等。注意这里看到的是等待时的瞬时参数，不能仅凭单条记录下结论，应该结合次数和平均等待时间。
Cache Fusion虽然避免了磁盘I/O，但每次块传输都要经过私有网络和远程实例的CPU处理，因此当传输次数过高时，gc等待会快速膨胀。需要特别区分的是，gc cr block多发生在查询频繁访问远端已提交数据时，而gc current block多发生在多个节点同时修改相同数据块时。两者都指向全局缓存协调，但优化方向可能完全不同。
SELECT event, total_waits, time_waited_micro, average_wait
FROM v$system_event
WHERE event IN ('gc cr block','gc current block')
ORDER BY time_waited_micro DESC;
二、借助等待事件定位热点对象
定位gc等待问题首先需要确定是哪些数据块在频繁进行全局传输。v$session视图可以展示当前正在等待的会话以及p1、p2参数，配合dba_extents可以快速找到对应的段。实时抓取比只看AWR更直接，尤其在业务高峰期间，可以在短时间内抓取多个样本，分析是否集中在相同的文件号和块号。
一个更高效的视图是v$segment_statistics，它直接记录了段级别的gc cr blocks received和gc current blocks received等统计数据。通过查询该视图，可以快速找出接收远程块最频繁的表或索引。如果某个小表的记录数很少，但gc cr blocks received数值很高，通常说明该表被多个节点高频全表扫描，或者频繁执行SELECT FOR UPDATE等当前读操作。还可以结合v$sql或AWR中的SQL报告，确认访问该对象的SQL是否存在不必要的全表扫描。
SELECT owner, object_name, subobject_name, statistic_name, value
FROM v$segment_statistics
WHERE statistic_name IN ('gc cr blocks received','gc current blocks received')
AND value > 0
ORDER BY value DESC
FETCH FIRST 20 ROWS ONLY;
除段级统计外，还需要关注系统级统计值。gv$sysstat中记录了gc cr blocks received、gc current blocks received以及对应的接收时间，按实例汇总可以看出不同节点在Cache Fusion中的不对称性。例如节点1接收的块远多于节点2，可能说明应用连接分发不均衡，或者某些数据被固定在少数节点访问。如果两个节点接收量都很高，说明数据访问本身存在较强竞争，需要从应用路径上解决。
SELECT inst_id, name, value
FROM gv$sysstat
WHERE name IN ('gc cr blocks received','gc current blocks received',
'gc cr block receive time','gc current block receive time')
ORDER BY inst_id, name;
三、常见原因与优化策略
从实际案例看，gc cr/current block等待通常由三类原因引起。第一类是应用层热点块，例如多个节点都频繁修改同一个数据块。典型场景包括高并发更新同一行或同一组行、序列生成的唯一键值顺序插入、以及大小非常小的表被反复全表扫描。这时即使私有网络带宽充足，也无法避免全局锁竞争，因为请求集中在少数块上。
针对热点块，优先考虑减少并发争抢同一块。对于序列，可以增大缓存值，使节点在本地批量生成序列值而减少全局块交换。对于顺序插入导致的右侧索引热点，可以使用反转索引或哈希分区索引，将集中写入分散到多个索引块。对于频繁访问的小表，检查SQL是否真的需要频繁全表扫描，如果必须跨节点访问，也可以考虑将小表设计为单节点本地访问，通过服务配置固定到某个实例，减少远程块传输。
第二类是SQL执行计划不合理，导致海量逻辑读和全局块请求。例如原本应该使用索引范围扫描的SQL错误走了全表扫描，或者nested loop连接中内层驱动表的选择不当，导致大量随机块传递。此时优化执行计划往往能立竿见影，需要结合AWR中的Top SQL和SQL Monitor报告查看逻辑读、执行次数以及gc事件分布。
SELECT sql_id, executions, buffer_gets, disk_reads, cpu_time, elapsed_time
FROM v$sqlstats
WHERE sql_id IN (
SELECT sql_id FROM v$session WHERE event IN ('gc cr block','gc current block')
)
ORDER BY buffer_gets DESC;
第三类是私有网络问题。Cache Fusion中的块传输对私有网络的延迟和带宽非常敏感。很多生产环境把业务流量和心跳流量混在同一张网卡上，或者使用旧版交换机和高延迟链路，会直接抬高gc等待时间。优化时需要检查网卡丢包、重传、交换机端口队列，以及Oracle UDP缓冲区参数。虽然现代RAC多使用默认UDP协议，但网络基础架构的稳定性比单纯提高带宽更重要。
四、建立持续监控与验证
优化不能只停留在分析阶段，建立持续的gc等待监控有助于在问题出现前发现趋势。可以定期采集gv$sysstat和v$segment_statistics数据，形成基线。重点关注gc cr block receive time与gc cr blocks received的比例，即平均接收时间。如果块接收数量没有明显增加，但平均接收时间显著上升，说明网络或远程实例处理能力可能出现了瓶颈。
在修改参数或调整应用逻辑后，需要对比优化前后的AWR报告。AWR中的Global Cache Load Profile部分可以显示gc cr/current block的等待次数和平均等待时间。如果调整有效，可以看到相同业务压力下gc等待时间占比下降，而SQL逻辑读变化不大。验证时要保持业务负载可比性，最好选择相同时间段或压测结果进行对比。
下面是一个简单的日常巡检SQL，按小时统计两个gc等待事件的累计次数，适合放入监控脚本中周期性执行。通过趋势分析，可以在gc等待突然升高时及时定位到开始出现异常的时间点，并关联当时的新上线SQL或数据增长情况。
SELECT TO_CHAR(sample_time, 'YYYY-MM-DD HH24') AS hour,
SUM(CASE WHEN event = 'gc cr block' THEN 1 ELSE 0 END) AS cr_count,
SUM(CASE WHEN event = 'gc current block' THEN 1 ELSE 0 END) AS cur_count
FROM v$active_session_history
WHERE event IN ('gc cr block','gc current block')
AND sample_time > SYSDATE - 1
GROUP BY TO_CHAR(sample_time, 'YYYY-MM-DD HH24')
ORDER BY hour;
通过上述步骤，DBA可以从原理出发，利用动态性能视图和AWR历史数据逐步缩小范围，梳理出是热点对象、SQL设计还是网络链路导致gc等待居高不下，并制定针对性优化方案。
Oracle RACgc cr/current block等待事件修改时间：2026-08-25 14:24:30