并行刷新参数 parallelism 并非越大越好，需根据资源、物化视图结构及日志配置综合设定；推荐值为2~4，须配合 atomic_refresh => FALSE 才能真正发挥并行效果，并确保物化视图日志支持 FAST 刷新。
并行刷新参数 parallelism 不是开得越大越好
设置
后，
oracle
会启用并行查询服务器（px servers）执行物化视图重建或日志应用，但实际加速效果受限于底层资源和物化视图结构本身。常见误区是直接设成 8 或 16，结果反而因争用
或临时段 i/o 拖慢整体速度。
（默认）：串行执行，锁持有时间长，适合小 MV 或低负载环境
：对中等规模（百万级行）、含聚合或连接的 MV 最常见效的范围
：极易触发 PX server 耗尽、大量
等待，反而更慢
若物化视图基表来自 DBLink，
仅作用于本地端计算，远程部分仍串行，收益大幅衰减
必须配合 atomic_refresh => FALSE 才能真正释放并行潜力
默认
强制整个刷新在一个事务内完成，即使开了并行，所有 PX 进程仍需共享同一 undo 段、等待统一提交。大 MV 下极易卡在
或触发 ORA-01555。
加
后，并行进程可分批次提交（例如每 10 万行 commit 一次），显著降低锁粒度和 undo 压力
代价是刷新过程中物化视图可能短暂返回不一致数据（如部分新数据 + 部分旧数据），业务查询需容忍此窗口
不要同时设
和
：出错后跳过失败批次时，已提交的部分无法回滚，状态更难追踪
并行刷新前务必检查物化视图日志是否支持并行 FAST 刷新
如果物化视图定义为
，但日志里没带
或主键字段缺失，Oracle 会在并行执行时悄悄退化为串行 COMPLETE 刷新——你看到的是“并行参数生效”，实际跑的却是单线程全量重建。
查日志结构：
关键项必须为
：特别是
（保证变更顺序）和
（避免 ROWID 失效）
若日志只有
，且基表频繁做 MOVE / SHRINK，FAST 刷新会失败，此时并行毫无意义，应直接切
监控并行刷新是否真正在起效
光看 PL/SQL 执行成功不代表并行被正确利用。很多情况下
参数被忽略，或只在部分阶段启用。
oracle知识库
oracle知识库下载
下载
查实时并行活动：
查执行计划是否含
操作符：
（替换为刷新语句对应 SQL_ID）
留意 AWR 报告中 “Parallel Operations” 部分的
，若长期为 0 或极低，说明并行未真正下发
最常被忽略的一点：并行刷新对物化视图本身的 SQL 复杂度敏感。如果 SELECT 中含标量子查询、UDF 或未分析的统计信息，优化器可能直接拒绝并行化，此时调高
完全无效——先确保基础执行计划能并行，再谈参数调整。
parallelismparallel_max_serversparallelism => 0parallelism => 2~4parallelism > CPU_COUNT * 2enq: PS - contentionparallelismatomic_refresh => TRUEenq: TX - row lock contentionatomic_refresh => FALSErefresh_after_errors => TRUEatomic_refresh => FALSEREFRESH FASTSEQUENCESELECT LOG_TABLE, ROWIDS, PRIMARY_KEY, OBJECT_ID, SEQUENCE FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE';YESSEQUENCEPRIMARY_KEYROWIDmethod => 'C'parallelismSELECT QC_INSTANCE_ID, QC_SESSION_ID, SERVER_SET, DEGREE FROM V$PX_SESSION WHERE QCSID IN (SELECT SID FROM V$SESSION WHERE MODULE LIKE '%DBMS_MVIEW%');PXSELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id_here'));Parallel Execution Message Sizeparallelism