判断gc设计是否合理应先看gv$system_event中等待时间分布：若gc cr block busy突增于16ms桶是网络抖动，集中于1ms/4ms桶则为锁争用或sql问题；再结合gv$sql中高buffer_gets低disk_reads语句及10046 trace定位gc密集sql。
缓存融合（cache fusion）本身不直接“调网络延迟”，但网络延迟会放大它的开销——优化方向必须从“减少gc流量”和“让gc更耐抖动”两头下手，而不是盲目压低ping值。
怎么判断是网络延迟真高，还是GC设计不合理？
很多 DBA 一看到 gc cr block 2-way 等待时间长，就去查交换机、换网卡、调MTU，结果收效甚微。真正该先看的，是这些指标：
- 查
GV$SYSTEM_EVENT中gc cr block busy和gc current block busy的 16ms 桶占比：如果突增，才是网络抖动或中断；如果集中在 1ms/4ms 桶，大概率是锁争用或SQL访问模式问题 - 对比
GV$SQL中buffer_gets/executions高但disk_reads/executions低的语句——这类 SQL 在单实例跑得飞快，在 RAC 上却疯狂触发 GC - 用
ALTER SYSTEM SET EVENTS '10046 trace name context forever, level 8'抓 GC 密集会话，看 trace 里WAIT #1: nam='gc current block 2-way'后面紧跟着的是什么 SQL，往往就是未绑定变量的循环 INSERT 或全表扫描 JOIN
哪些隐式参数能真正降低 GC 对网络延迟的敏感度？
Oracle 不公开文档里写明的“抗延迟”参数，但生产中验证有效的有这几个：
-
_gc_affinity_time = 10：让数据块在本地节点多留 10 秒，减少跨节点迁移频率。适用于读多写少、热点相对固定的场景 -
_gc_affinity_percent = 50：只有当本地访问占比低于 50% 时才考虑迁走块。配合_gc_affinity_time使用，避免“刚热起来就被踢走” -
_gc_read_mostly_locking = TRUE：对只读为主的数据对象启用轻量级锁机制，大幅减少 GES 协调开销。注意：仅适用于明确标记为 READ ONLY 的表空间或分区 - 慎用
_gc_lms_processes：默认 2，可设为 4，但超过 4 容易引发 LMS 进程间竞争，反而增加 CPU 开销
用 ifconfig / ethtool 看网络，为什么总误判带宽利用率？
很多人拿 ifconfig eth2 输出的 RX/TX 字节数除以理论带宽，算出“利用率才 30%”，就认为网络没问题。这是典型误判：
-
ifconfig统计的是 L2 层字节数（含以太网头 + CRC），而 Oracle GC 流量是 TCP 载荷，每包多出约 40–60 字节——直接套用会高估 15%–20% 利用率 - 真正要看的是
ethtool -S eth2里的rx_discards和tx_aborted_errors：非零值基本指向网卡驱动缺陷或交换机 QoS 限速，不是配置问题 - 用
iftop -P tcp -f "port 6200 or port 6201"（GCS/GES 默认端口）抓实时流量分布，确认是不是某两个节点之间流量压倒性偏高——这才是真实瓶颈点
SCN 同步延迟也会伪装成 GC 延迟
当 MAX_COMMIT_PROPAGATION_DELAY 保持默认（700–1000 厘秒），一个实例提交后，其他节点可能要等几秒才拿到最新 SCN。这会导致：
- 后续查询被阻塞在
gc cr block busy，因为等待 SCN 推进 - AWR 里看不到明显网络错误，但
GV$TRANSACTION中USED_UBLK持续增长、START_SCN滞后 - 调低该参数（如设为 100）能缓解，但代价是 LGWR 更频繁广播——需权衡日志吞吐与事务顺序性
真正难处理的，是那些既不显现在 AWR 等待事件里、也不报错，但会让 GC 流量在特定时段突然翻倍的 SQL 模式——比如应用层分页用 ROWNUM 加循环重试，每次重试都触发全新 CR 请求。这种问题，永远比网线松动更隐蔽。
