gc cr multi block request高≠网络故障，本质是全表扫描或索引快速全扫描触发的批量cr块请求；avg wait>50ms才需查网络或lms，否则优先优化sql和对象设计。
gc cr multi block request 高 ≠ 网络故障
看到这个等待排进 AWR Top 5，第一反应不是立刻查私网丢包，而是先确认是否在做全表扫描或索引快速全扫描。它本质是批量 CR 块请求，db file scattered read 出现时，gc cr multi block request 必然伴随——这是 Cache Fusion 的正常行为，不是 bug，也不是配置错误的铁证。
真正要警惕的是它的 Avg wait (ms)：如果长期 > 50ms，才说明传输链路或资源调度出了问题；若仅 1–5ms 但次数极高，大概率是业务 SQL 本身触发了大量跨节点扫描。
DB_FILE_MULTIBLOCK_READ_COUNT 设置过大
该参数直接决定单次请求的块数。默认值在 11g+ 是 128（AIX/HP-UX 可能更高），而私网带宽和 UDP 缓冲区往往按旧标准（如 16 或 32）调优过。结果就是：一次请求压垮网络接收队列，LMS 来不及打包发送，远程实例反复重传。
- 检查当前值：
SHOW PARAMETER db_file_multiblock_read_count - 生产建议值：通常设为 16–32，尤其当
db_block_size= 8192 时，单次请求不超过 256KB - 注意：该参数不重启生效，但新会话才用新值；已有长查询不会中断，需等其结束
UDP 缓冲区不足导致 packet receive errors
netstat -su 输出中若出现 packet receive errors > 0，基本可锁定 UDP 接收缓存溢出。RAC 所有 GC 消息走 UDP，没有重传保障，丢一个包就可能触发整批重发，放大等待时间。
AIX 示例（其他平台类似逻辑）：
- 当前
udp_recvspace应 ≥(db_block_size * db_file_multiblock_read_count) + 4096 - 底线值不能低于
65536；若用 128 × 8192 = 1MB 请求，udp_recvspace至少设为1052672 - 修改后必须重启数据库实例（LMS 进程初始化时读取 OS 参数）
LMS 进程数不足或负载不均
LMS 负责打包、发送、响应所有 multi block 请求。若实例间 LMS 数量不一致（如升级后自动调整未干预），或某节点 CPU 被其他进程占满导致 LMS 调度延迟，就会在 gc cr multi block request 上体现为高平均等待。
验证方式：
- 查各实例 LMS 数：
SELECT inst_id, COUNT(*) FROM gv$process WHERE program LIKE '%LMS%' GROUP BY inst_id - 查 LMS CPU 占用：
top -p $(pgrep -f "ora_lms")（Linux） - 关键动作：统一设置
_lm_lms隐含参数（如ALTER SYSTEM SET "_lm_lms"=4 SCOPE=SPFILE），并确保所有实例重启后值一致
最后提醒：别在 gv$session_wait 里只盯 event，一定要结合 current_file# 和 current_block# 定位到具体对象——很多 case 最终发现是某张未分区的大表被多个实例并发扫，而非参数或网络问题。
