'gc cr multi block request'高表明RAC跨节点CR块传输瓶颈，非IO慢：单次等待>10ms、与db file scattered read及gc cr grant 2-way同步升高；需调低DB_FILE_MULTIBLOCK_READ_COUNT并增大UDP缓存，检查LMS数量/优先级/DRM状态，验证分区亲和性。
为什么'gc cr multi block request'高就代表扫描卡在私网传输上
这个等待不是IO慢，而是实例A发起全表扫描时，需要从其他节点批量拉取CR块（一次请求多块），但实际传输卡住了。关键特征是：单次等待时间长（>10ms）、AWR里和db file scattered read成对出现、gc cr grant 2-way也同步升高。它暴露的是跨节点数据搬运链路的瓶颈，不是磁盘或SQL本身问题。
先检查DB_FILE_MULTIBLOCK_READ_COUNT和UDP缓冲区是否失配
这是最常被忽略的配置冲突点。默认DB_FILE_MULTIBLOCK_READ_COUNT设为128或更高，在RAC下会导致单次GC请求打包太多块，私网UDP包超限丢弃。必须同步调低并放大OS层UDP缓存：
- AIX系统：
udp_sendspace至少设为DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT * 2，udp_recvspace≥udp_sendspace * 1.5 - Linux系统：调整
/proc/sys/net/ipv4/udp_mem三元组，第二值（压力阈值）建议 ≥ 256MB - Oracle侧立即生效：用
ALTER SYSTEM SET db_file_multiblock_read_count = 16 SCOPE=BOTH（8K块下不超128KB/次）
确认LMS进程是否成为瓶颈
当gc cr multi block request平均等待时间突增且伴随CPU使用率飙升，大概率是LMS没跟上请求节奏。重点查三点：
- 当前LMS数量：
SELECT inst_id, name, value FROM gv$parameter WHERE name = 'gcs_server_processes'，确保各节点值一致且≥CPU核数×0.5 - LMS是否实时调度：Linux下用
chrt -p $(pgrep -f "lms")确认优先级为SCHED_RR，否则加chrt -r -p 99 [pid] - 是否存在DRM冻结：查
v$gcspfmaster_info中state列是否长期为FROZEN，是则需检查_gc_affinity_time是否过短
分区亲和性与扫描模式是否匹配
即使网络和LMS都正常，如果扫描对象没按实例访问模式分区，照样会触发跨节点多块拉取。验证方式：
- 查
gv$bh中热点段的inst_id分布：SELECT inst_id, COUNT(*) FROM gv$bh WHERE objd = [obj_id] GROUP BY inst_id，若多个实例缓存同一块说明亲和性失效 - 强制绑定服务名执行扫描：
SELECT /*+ FULL(t) */ COUNT(*) FROM t@svc_name，对比不同服务名下的等待差异 - 对大表启用
_gc_read_mostly_locking=TRUE并配合gc_files_to_locks按文件粒度控制主节点归属
真正难调的从来不是参数数字，而是让数据块“该在哪就在哪”——一旦发现gc cr multi block request集中在某几个file#，立刻顺着dba_extents反查分区定义，而不是继续调UDP缓存。
