应先查SQL访问模式和数据分布，而非直接调网络；通过GV$SYSTEM_EVENT中16ms等待桶占比突增判断真网络问题，否则多为锁争用、热点块或未绑定变量所致。
gc cr block 2-way 等待高，不是网络慢的直接证据，而是“cr块请求路径不高效”的信号——真正该先查的是sql访问模式和数据分布，不是立刻调网卡或换交换机。
怎么快速判断是真网络问题，还是SQL/对象设计问题？
看 GV$SYSTEM_EVENT 中该等待的等待时间分布桶（1ms、4ms、16ms 桶）：
- 若
16ms桶占比突增（比如从 5% 跳到 40%），才可能是私网丢包、中断或交换机抖动 - 若集中在
1ms或4ms桶，基本排除网络延迟，大概率是锁争用、热点块（如索引根块）、或未绑定变量导致的全表扫描反复触发 CR 请求 - 同步查
GV$SQL：找buffer_gets/executions高但disk_reads/executions极低的语句——这类 SQL 在单实例飞快，在 RAC 上却疯狂刷gc cr block 2-way
哪些 SQL 最容易引发 gc cr block 2-way 暴涨？
不是所有高逻辑读 SQL 都会触发大量 CR 流量，关键看是否“跨节点读历史版本”：
- 未绑定变量的循环
INSERT INTO t VALUES (:1, :2)—— 每次硬解析可能走不同执行计划，部分走全表扫描，触发大量 CR 块构造 - 高频查询序列号表（如
SEQ_ORDER_ID.NEXTVAL）—— 索引根块被多实例反复争抢，CR 请求密集 - 按非分区键字段查询 RANGE 分区表（如按
STATUS查，但表按CREATED_DATE分区）—— 查询打散到多个实例，本地无缓存，频繁远程构造 CR - 缺少索引的 JOIN 条件（如
WHERE a.id = b.id但b.id无索引）—— 全表扫描驱动表，每行都需构造 CR 块
隐式参数能缓解，但不能替代 SQL 和对象优化
Oracle 没有公开“抗延迟”开关，但以下参数在生产中验证过对降低 GC 敏感度有效：
-
_gc_affinity_time = 10：让数据块在本地实例多留 10 秒，减少刚热起来就被迁走。适用于读多写少、热点稳定的场景 -
_gc_affinity_percent = 50：只有当本地访问占比低于 50% 才考虑迁移块。必须配合_gc_affinity_time使用，否则无效 -
_gc_read_mostly_locking = TRUE：仅对显式标记为READ ONLY的表空间或分区生效，可大幅减少 GES 协调开销
注意：_gc_* 是隐式参数，修改前务必在测试环境验证；且它们只让 GC “更耐抖动”，无法解决因 SQL 全表扫描或热点行更新带来的根本流量压力。
抓 trace 定位真实瓶颈，别靠猜
用 ALTER SYSTEM SET EVENTS '10046 trace name context forever, level 8' 抓一个高 gc cr block 2-way 的会话，重点看 trace 文件里：
-
WAIT #1: nam='gc cr block 2-way'后面紧跟着的是哪条 SQL —— 往往就是罪魁祸首 - 同一 SQL 是否反复出现
WAIT #N: nam='gc current block busy'—— 表明持有者正在写该块，CR 构造被阻塞 - 是否有大量
EXEC #1后紧跟WAIT #2（即 parse-exec-wait 循环）—— 指向绑定变量缺失或游标未重用
真正难处理的，从来不是 ping 延迟多 0.2ms，而是某张配置表被 100 个应用进程轮着 SELECT FOR UPDATE，每次都要跨节点构造 CR 块——这种问题，调 MTU 没用，得改应用逻辑或加应用级缓存。
