RAC中物化视图刷新变慢的根本原因是全局缓存（GC）争用被放大，而非并发不足；并行刷新需配合atomic_refresh=>FALSE、日志结构验证及合理分区设计才能生效。
并行刷新参数 parallelism 在 RAC 下极易失效，必须配合 atomic_refresh => FALSE 和日志结构验证才能起效
为什么 RAC 中物化视图刷新变慢？
RAC 环境下物化视图刷新慢，根本原因不是“并发不够”，而是全局缓存（GC）争用被放大。物化视图刷新过程涉及大量基表块读取、日志表（MLOG$_xxx）扫描和目标 MV 表写入——这些操作在多实例间频繁触发 gc current block busy 和 gc cr block busy 等等待。尤其当基表或日志表未分区、主键单调递增、或刷新任务集中在单个节点执行时，热点块争用会直接卡住整个并行链路。
常见错误现象包括：
- 设置
parallelism => 8后，V$PX_SESSION显示 PX 进程启动，但实际刷新耗时反而比串行更长 - AWR 报告中 “Global Cache and Enqueue Statistics” 显示
gc current block busy占比超 30% - 刷新过程中出现大量
enq: TX - row lock contention或enq: PS - contention
parallelism 参数在 RAC 下怎么设才不翻车？
RAC 中 parallelism 不是简单按 CPU 核数翻倍，而要受限于 GC 能力和跨节点数据传输开销。盲目调高只会加剧 px server 争抢和 buffer busy 等待。
-
parallelism => 0（默认）：串行执行，锁持有时间长，但 GC 压力最小，适合小 MV 或日志表极小的场景 -
parallelism => 2~3：对中等规模 MV（百万级行）、基表已按时间/ID 分区、且日志表也做了对应分区的组合最稳妥 -
parallelism > 4：仅在满足以下全部条件时可尝试：① 基表和日志表均按相同列做范围/列表分区；② 刷新语句中明确加了分区裁剪谓词（如WHERE dt >= TRUNC(SYSDATE) - 7）；③_gc_read_mostly_locking = TRUE已启用 - 绝对避免
parallelism > CPU_COUNT * 2：RAC 下parallel_max_servers很容易耗尽，引发大量enq: PS - contention
必须关掉 atomic_refresh => TRUE 吗？
必须关。RAC 下 atomic_refresh => TRUE 是性能杀手。
它强制所有并行进程共享同一事务、同一 undo 段，并在最后统一提交。这导致：
- 所有 PX 进程反复争抢同一个 undo segment header 块，触发
enq: US - contention - 事务时间拉长，GC 锁无法及时释放，其他节点查询基表时卡在
gc current block busy - 一旦失败，整个刷新回滚代价极高，且可能拖垮其他正在运行的 MV 刷新任务
改用 atomic_refresh => FALSE 后，每个 PX 进程可独立提交（默认每 10 万行 commit 一次），大幅降低锁粒度和 undo 压力。代价是刷新窗口内 MV 数据短暂不一致——业务查询需接受这个事实，不能依赖“强一致性”语义。
日志表和基表结构怎么配合 RAC 刷新？
RAC 下 FAST 刷新退化为 COMPLETE 的隐蔽性更强。即使 DBA_MVIEWS.FAST_REFRESHABLE = 'YES'，也可能因结构不匹配在运行时静默降级。
- 基表必须有稳定主键，且日志建时显式声明
WITH PRIMARY KEY；若用WITH ROWID，基表一旦发生MOVE或SHRINK，FAST 刷新立即失败 - 日志表（
MLOG$_xxx）必须含SEQUENCE$$字段（用于保证变更顺序），否则并行应用日志时可能乱序更新 - 若基表是分区表，强烈建议日志表也按相同策略分区（如按
SNAPTIME$$或基表分区键），否则全表扫描日志会引发严重 GC 争用 - 刷新前务必执行：
SELECT COUNT(*) FROM MLOG$_t WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_T')，非零才说明增量路径真在走
真正难调的点不在参数本身，而在基表与日志表的物理布局是否适配 RAC 的缓存分发机制——一个没分区的日志表，在 4 节点 RAC 上刷一次，可能比单实例慢 5 倍以上，且你从执行计划里完全看不出问题。
