parallelism参数仅对COMPLETE刷新生效，FAST刷新完全忽略；COMPLETE刷新时转为SQL层PARALLEL Hint，FORCE模式下若退化为COMPLETE才生效，否则静默丢弃。
dbms_mview.refresh 的 parallelism 参数是否真起作用？
起作用，但仅对 COMPLETE 刷新生效；FAST 刷新完全忽略该参数。Oracle 内部对快速刷新采用单线程 delta 合并逻辑，硬编码不支持并行——哪怕你传 PARALLELISM => 16，执行计划里也看不到并行操作符。
验证方式：刷新时查 V$ALL_SQL_PLAN_MONITOR，若 plan_operation 出现 PX COORDINATOR 或 PX SEND，说明并行生效；FAST 刷新中只会看到 MERGE、TABLE ACCESS BY INDEX ROWID 等串行操作。
-
COMPLETE刷新会重跑整个AS子查询，此时PARALLELISM直接转为 SQL 层的/*+ PARALLEL(n) */Hint -
FORCE模式下，若退化为COMPLETE，则并行生效；若走FAST，则并行被静默丢弃 - 并行度上限受
PARALLEL_MAX_SERVERS和当前空闲 server 数量限制，超限会降级为串行
如何确认并行刷新实际启动了？
别只看 PL/SQL 执行成功，要抓底层 SQL 的运行时行为。关键步骤：
- 执行前确保
STATISTICS_LEVEL = TYPICAL（BASIC下V$ALL_SQL_PLAN_MONITOR无数据） - 用具备
SELECT_CATALOG_ROLE的用户执行刷新，否则监控视图不可见 - 刷新触发后立即查：
SELECT key, sql_id, sql_exec_id, status FROM v$all_sql_monitor WHERE sql_text LIKE '%your_mv_name%' AND status = 'EXECUTING'
- 拿到
key后查详细步骤：SELECT plan_line_id, plan_operation, dop, last_degree FROM v$all_sql_plan_monitor WHERE key = :key ORDER BY plan_line_id
—— 若dop > 1且出现PX类操作，才算真正并行
并行刷新常见卡点与绕过方法
即使参数正确、权限到位，并行刷新仍可能卡在某一步，最典型的是：
-
COMPLETE刷新时BUFFER_GETS高但DISK_READS低 → 表明大量内存排序（如 GROUP BY、ORDER BY），PGA 不足导致频繁写临时表；需调大PGA_AGGREGATE_TARGET或改写物化视图查询避免排序 - 并行进程被阻塞在
enq: TX - row lock contention→ 基表有长事务未提交，刷新会等锁；建议在业务低峰期执行或加ATOMIC_REFRESH => FALSE（先 truncate 再 insert，减少锁持有时间） - 使用
ON COMMIT模式时传PARALLELISM→ 无效且报错ORA-12054；ON COMMIT强制串行，这是 Oracle 硬性限制
并行刷新不是万能加速器
对小表或简单聚合，开并行反而增加调度开销；对含复杂连接、多层子查询的物化视图，PARALLELISM 可能放大统计信息偏差，导致执行计划劣化。真实场景中，应先用 EXPLAIN PLAN FOR 检查基础查询的并行可行性，再决定是否启用。另外，DBMS_MVIEW.REFRESH_ALL_MVIEWS 不支持全局并行控制，必须逐个调用并指定 PARALLELISM。
