大事务触发全局缓存争用本质是“抢”而非“慢”，因其引发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 来反推。
