parallelism设2~4最有效，超CPU_COUNT×2易引发PS争用；需配合atomic_refresh=>FALSE分批提交，并确保物化视图日志含SEQUENCE、主键/ROWID及所有SELECT列。
parallelism参数设多少才真正有效
并行刷新不是开得越大越快，parallelism 值超过 cpu_count * 2 后，反而容易触发 enq: ps - contention 等等待事件，拖慢整体速度。中等规模物化视图（百万级行、含聚合或连接）最常见效的范围是 2~4。
常见误区是直接设成 8 或 16，结果 PX server 耗尽、临时段 I/O 拥堵，刷新耗时翻倍。实操建议：
-
parallelism => 0（默认）：适合小 MV 或低负载环境，但锁持有时间长 -
parallelism => 2：多数 FAST 刷新场景的起点，资源压力小、加速明显 -
parallelism => 4：需确认PARALLEL_MAX_SERVERS足够且无其他高并发并行任务争用 - 若基表通过
DBLink访问，parallelism仅作用于本地端计算，远程部分仍串行，收益大幅衰减
atomic_refresh => FALSE 是并行生效的前提
默认 atomic_refresh => TRUE 会强制整个刷新在一个事务内完成，即使开了并行，所有 PX 进程仍共享同一 undo 段、等待统一提交，大 MV 下极易卡在 enq: TX - row lock contention 或触发 ORA-01555。
加 atomic_refresh => FALSE 后，并行进程可分批次提交（例如每 10 万行 commit 一次），显著降低锁粒度和 undo 压力。但代价是刷新过程中物化视图可能短暂返回不一致数据（部分新 + 部分旧），业务查询需容忍此窗口。
注意：refresh_after_errors => TRUE 和 atomic_refresh => FALSE 不要同时设——出错后跳过失败批次时，已提交的部分无法回滚，状态更难追踪。
为什么并行没起效？先查日志是否支持 FAST
很多情况下你看到 DBMS_MVIEW.REFRESH 执行成功，但实际跑的是串行 COMPLETE 刷新——因为物化视图日志不满足并行 FAST 条件，Oracle 自动降级了。
关键检查项（用 USER_MVIEW_LOGS）：
-
SEQUENCE字段必须为YES：保证变更顺序，缺它就退化为串行 -
PRIMARY_KEY或ROWID必须存在：否则 FAST 刷新可能失败，尤其基表做过MOVE/SHRINK - 日志里要包含物化视图
SELECT中所有列，包括分区键表达式（如TRUNC(SALES_DATE, 'MM')） - 执行
CREATE MATERIALIZED VIEW LOG ON t1 WITH ROWID, SEQUENCE(...)时必须带INCLUDING NEW VALUES
监控并行是否真正在跑，别只看 PL/SQL 成功
执行计划里看不到 PX 相关操作（如 PX COORDINATOR、PX SEND），或者 V$PX_SESSION 里没有活跃的并行进程，说明 parallelism 参数被忽略或只在部分阶段启用。
验证方法：
- 刷新时查
V$SESSION_EVENT，观察是否有大量direct path write temp或enq: PS - contention - 执行
SELECT * FROM V$PX_PROCESS_SYSSTAT WHERE STATISTIC LIKE '%server%'，确认并行服务器确有分配 - 对比开启前后
DBA_HIST_ACTIVE_SESS_HISTORY中该作业的等待事件分布
真正难调的点不在参数本身，而在日志结构与并行行为之间的隐式耦合——少一个 SEQUENCE，再多的 parallelism 也只是空转。
