gc current/cr block请求高主因是单块级实时grd同步与广播，非写量本身；每修改一新块即触发一次gc协调，10万行分散5000块则产生5000次2-way请求，且append、未绑定变量、索引热点、私网mtu不足、驱动参数缺失及热块未分区均会加剧该问题。
批量DML触发大量gc current/cr block请求的底层机制
不是“写得多所以GC多”，而是每次INSERT/UPDATE涉及新数据块时，LMS必须把块状态同步到GRD，并广播给其他节点——哪怕目标块当前只在本节点内存里。Oracle不会等你COMMIT才发消息，而是每修改一个块就触发一次global cache协调。10万行插入若分散在5000个不同数据块上，就会产生5000次gc current block 2-way请求，而非1次批量通知。
- APPEND模式不绕过GC：虽然direct path write跳过buffer cache，但新分配的数据块仍需注册到GRD，触发gc current grant 2-way
- 未绑定变量的循环DML：每次硬解析可能走不同执行计划，导致同一SQL在不同节点扫描不同数据段，CR请求路径完全发散
- 索引维护放大GC：每个索引键更新都对应独立的叶子块操作，高频插入单点序列（如SEQ.NEXTVAL）会让索引根块成为跨节点争用热点
为什么私网MTU=1500会让GC堵塞雪上加霜
GC消息不是小包。一个gc current block request实际包含block header + undo metadata + transaction info，轻松超过8KB；PARALLEL_EXECUTION_MESSAGE_SIZE默认16KB。MTU=1500强制拆成6–10个分片包，任意一个丢包就触发全包重传，LMS进程队列瞬间堆积。
- 用
ping -M do -s 8972 <other_node_private_ip></other_node_private_ip>测试：返回"Message too long"即MTU未调至9000 - netstat -su显示
UDPInOverflows持续增长，说明内核UDP接收缓冲区溢出，GC包被静默丢弃 - AWR中
gc cr multiblock requests等待时间固定为16ms或32ms，是典型分片重组失败特征
连接字符串里三个参数没配齐，批量DML必然抖动
ODP.NET Core驱动默认行为对批量场景极不友好，靠代码设置StatementCacheSize无效，必须写死在连接字符串里。
-
Statement Cache Size=100：设为0（默认）会导致每条INSERT都硬解析，共享池争用+系统视图查询（all_constraints等）直接拉高CPU -
Metadata Performance=Enabled：关闭时首次访问每张新表都要查系统视图，租户分表场景下元数据查询量指数级放大 -
Connection Timeout=30：RAC节点切换时连接卡在建立阶段，事务生命周期被拖长，GC协调窗口被迫延长
最容易被忽略的堵塞源头：热块未分区+单调主键
GC堵塞常被误判为网络或驱动问题，但真实瓶颈往往在数据分布层。压测中TPS卡在1100上不去，最终发现是4家大机构数据集中写入同一hash子分区，导致该分区索引根块被两个节点反复争抢gc buffer busy acquire。
- range-hash复合分区时，若二级hash数固定为64，但80%流量集中在4个值上，等于把压力压进6.25%的物理位置
- 流水表用
SEQ.NEXTVAL作主键：索引右倾，所有新记录挤在同一个叶子块，触发密集的gc current block busy - 检查
Segments by Global Cache Buffer Busy时，别只看表名——要连PARTITION_NAME一起查，否则漏掉热点子分区
