gc current block等待本质是写请求卡在块获取环节，即实例a需修改数据块但该块正被实例b缓存，必须等待b发送当前版本；卡点可能在私网、lms进程、块争用或路由错误，需依子事件（如2-way、busy、congested）精准定位根因。
gc current block等待本质是写请求卡在块获取环节
这不是IO慢或SQL写法问题，而是实例A要改某块，发现它正被实例B缓存着，必须等B把块发过来才能继续。整个链路卡点可能在私网、LMS进程、块争用或路由错误上。关键要看具体子事件：如果是gc current block 2-way，说明块确实在另一节点缓存；如果是gc current block busy，大概率是B正在改同一块没腾出手；gc current block congested则直接指向LMS过载。
先确认是不是真跨了节点再调优
很多“优化”动作其实白做，因为SQL压根没跨节点。查执行计划的IN-OUT列：出现PCWP或PCWC才表示有跨节点数据分发；只有PQ说明并行完全在本节点内完成。再查gv$sysstat里gc current blocks received和gc cr blocks received比值——如果前者远高于后者，说明大量写操作被迫拉取current块，加并行只会恶化。另外，用SELECT * FROM gv$session_wait WHERE event LIKE 'gc current%'抓活跃会话，看p1(file#)和p2(block#)，再用dba_extents反查具体对象，避免误判undo段或索引块。
网络和LMS是两大高频瓶颈点
私网延迟超过0.5ms或UDP丢包（netstat -su显示packet receive errors > 0）会直接放大所有gc等待。MTU不统一（比如一端1500一端9000）会导致分片重传，触发gc current block lost。LMS进程CPU持续>50%、或gv$ges_enqueue.cum_queue_time单次超100ms，就该怀疑LMS过载。此时检查GCS_SERVER_PROCESSES是否随物理CPU扩容调整，Linux下还需用chrt -r给LMS设实时调度优先级。别忽略crsctl stat res -t -w "TYPE = ora.lms.type"，LMS资源异常时它可能已offline但没报错。
应用层亲和性设计比参数调优更有效
参数如PARALLEL_FORCE_LOCAL或_gc_policy_time治标不治本。真正见效的是让DML尽量落在数据所在节点：服务名绑定SERVERPOOL + FAILOVER_TYPE=SELECT仅对查询生效，DML必须靠应用层路由。分区表按INSTANCE_NUMBER或业务维度（如租户ID）做局部化分区，索引也得是本地分区，否则每次更新都要跨节点同步索引块。如果已有热点表（如计数器），拆成多行或多表+MOD哈希分散写压力，比调INITRANS或FREELISTS实际得多。
最容易被忽略的是：备库节点执行查询慢，有时根本不是gc问题，而是主备版本不一致触发了隐藏Bug（比如19.15 vs 19.23），导致执行计划生成逻辑不同。这种case查gv$session_wait可能看不到gc等待，但10046 trace里会有大量DFS lock handle或非预期的远程调用。先确认两节点补丁集是否完全一致，再动手调gc。
