并行刷新参数 parallelism 并非越大越好，需根据资源、物化视图结构及日志配置综合设定；推荐值为2~4，须配合 atomic_refresh => FALSE 才能真正发挥并行效果，并确保物化视图日志支持 FAST 刷新。
并行刷新参数 parallelism 不是开得越大越好
设置 parallelism 后，oracle 会启用并行查询服务器（px servers）执行物化视图重建或日志应用，但实际加速效果受限于底层资源和物化视图结构本身。常见误区是直接设成 8 或 16，结果反而因争用 parallel_max_servers 或临时段 i/o 拖慢整体速度。
-
parallelism => 0（默认）：串行执行，锁持有时间长，适合小 MV 或低负载环境 -
parallelism => 2~4：对中等规模（百万级行）、含聚合或连接的 MV 最常见效的范围 -
parallelism > CPU_COUNT * 2：极易触发 PX server 耗尽、大量enq: PS - contention等待，反而更慢 - 若物化视图基表来自 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 刷新
如果物化视图定义为 REFRESH FAST，但日志里没带 SEQUENCE 或主键字段缺失，Oracle 会在并行执行时悄悄退化为串行 COMPLETE 刷新——你看到的是“并行参数生效”，实际跑的却是单线程全量重建。
- 查日志结构：
SELECT LOG_TABLE, ROWIDS, PRIMARY_KEY, OBJECT_ID, SEQUENCE FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'; - 关键项必须为
YES：特别是SEQUENCE（保证变更顺序）和PRIMARY_KEY（避免 ROWID 失效） - 若日志只有
ROWID，且基表频繁做 MOVE / SHRINK，FAST 刷新会失败，此时并行毫无意义，应直接切method => 'C'
监控并行刷新是否真正在起效
光看 PL/SQL 执行成功不代表并行被正确利用。很多情况下 parallelism 参数被忽略，或只在部分阶段启用。
- 查实时并行活动：
SELECT 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%'); - 查执行计划是否含
PX操作符：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id_here'));（替换为刷新语句对应 SQL_ID） - 留意 AWR 报告中 “Parallel Operations” 部分的
Parallel Execution Message Size，若长期为 0 或极低，说明并行未真正下发
最常被忽略的一点：并行刷新对物化视图本身的 SQL 复杂度敏感。如果 SELECT 中含标量子查询、UDF 或未分析的统计信息，优化器可能直接拒绝并行化，此时调高 parallelism 完全无效——先确保基础执行计划能并行，再谈参数调整。
