为什么Oracle RAC执行大事务会导致其他节点卡顿

大事务触发全局缓存争用本质是“抢”而非“慢”，因其引发gc cr/current block传输风暴，导致私网带宽打满、gc buffer busy acquire陡增、gc cr blocks received异常升高；此时CPU可能不高，但跨节点块争用激烈，需查v$transaction中used_ublk>10000的事务并关联gv$session定位SQL，避免盲目拆事务或调MAX_COMMIT_PROPAGATION_DELAY。

大事务触发全局缓存争用，不是“慢”，是“抢”

oracle rac 中大事务本身不直接让其他节点卡顿，真正起作用的是它引发的 gc cr block 和 gc current block 传输风暴。一个实例在修改大量数据块时，会不断广播脏块（current）和构造一致性读块（cr），其他节点只要访问这些块，就必须跨私网去拉——这本质是资源争抢，不是延迟。

常见错误现象包括：gc buffer busy acquire 等待陡增、gc cr blocks received 指标远高于平时、global cache cr block receive time 平均值飙升到毫秒级。此时看 CPU 可能不高，但私网带宽打满，ifconfig 能看到 eth1（或私网接口）的 TX 包量异常高。

• 不要只盯着 SQL 执行时间：同一语句在不同节点耗时差异大，大概率是 GC 流量分布不均，而非执行计划问题
• 避免“把大事务拆小”这种直觉操作：拆成多个小事务反而增加 commit 频次，放大 MAX_COMMIT_PROPAGATION_DELAY 带来的 SCN 同步抖动
• 确认是否真为大事务引起：查 v$transaction 中 used_ublk > 10000 的事务，再关联 gv$session 看其 sql_id 是否正在跑批处理

并行回滚（fast_start_parallel_rollback）会让卡顿雪上加霜

当大事务被 kill 或异常中断，Oracle 默认启用并行回滚（fast_start_parallel_rollback=LOW），启动约 2×CPU 数量的恢复进程。这些进程不走常规调度路径，而是由 SMON 直接抢占资源，极易导致：

• enq: TX - row lock contention 等待持续升高，因为回滚进程在反复申请 TX 锁
• 大量 PS（Parallel Server）进程占用 CPU，v$process 中状态为 RECOVERY 的进程数激增
• v$fast_start_transactions 显示 state = 'ROLLING BACK' 且 sofar 几乎不动，说明并行恢复已卡死

此时最有效动作是：立即执行 alter system set fast_start_parallel_rollback = false，然后重启实例。注意该参数动态设置无效，必须重启才生效——否则并行进程不会退出，只是不再新建。

SCN 同步延迟放大事务可见性偏差

大事务提交时，其 SCN 不会实时广播给所有节点，而是受 MAX_COMMIT_PROPAGATION_DELAY 控制（默认 700–1000 厘秒）。这意味着：

• 节点 A 刚提交一个更新了 50 万行的事务，节点 B 可能在 7 秒内仍用旧 SCN 构造 CR 块，导致重复拉取、版本链遍历变长
• 若业务依赖 SELECT ... FOR UPDATE WAIT 或应用层乐观锁（如 version 字段比对），会因 SCN 不一致误判“无变更”，引发逻辑错误
• 调低该参数（如设为 100）不能根治问题，反而可能压垮私网——实测在 16 节点集群中设为 200 后，LMD 进程 CPU 持续 > 90%

真正要盯的是 gv$database 中各节点的 current_scn 差值：超过 10⁶ 就值得警惕，说明 SCN 同步已滞后于业务节奏。

业务层未统一访问顺序，让死锁检测延迟暴露设计缺陷

RAC 死锁检测周期由隐含参数 _lm_dd_interval 控制（默认 60 秒），远长于单机的秒级响应。这不是 bug，是权衡私网开销的结果。当两个节点分别执行：

Node1: UPDATE t1 SET x=1 WHERE id=1; UPDATE t2 SET y=1 WHERE id=2;Node2: UPDATE t2 SET y=2 WHERE id=2; UPDATE t1 SET x=2 WHERE id=1;

——这类交叉更新在 RAC 中极可能卡满 60 秒才报 ORA-00060，期间所有相关会话都堵在 enq: TX - row lock contention 上。

• 别指望靠加索引或重试解决：索引只能加速单条语句，无法改变跨节点锁获取顺序
• 查 v$ges_blocking_enqueue 比查 gv$session.blocking_session 更可靠，后者对瞬时 GC 等待经常为空
• 业务代码必须强制主键升序更新：统一按 ORDER BY id 处理批量更新，从根源消除循环等待可能

最易被忽略的一点：RAC 下死锁 TRACE 不在 _ORA_*.TRC，而在 _LMD_*.TRC，且不含绑定值和行级上下文——这意味着你永远没法靠日志还原出“哪两行被锁”，只能靠 LOGMINER 解析归档日志中的 XID 来反推。