物化视图刷新并行度由会话级设置（如alter session enable parallel dml）、底层查询并行提示及系统参数（如parallel_max_servers）共同控制，其中启用parallel dml是硬性前提。
物化视图刷新时并行度由谁控制？
物化视图（mv）刷新的并行度不取决于 mv 自身定义，而是由执行刷新操作时的会话级设置、底层查询的并行提示，以及系统级参数共同决定。最关键的是：alter session enable parallel dml 必须显式启用，否则即使 mv 查询含 px（并行执行）能力，dbms_mview.refresh 仍走串行路径。
常见错误现象：明明表加了 PARALLEL 4，刷新时 v$session_longops 却只看到 1 个 slave；或 EXPLAIN PLAN 显示并行计划，但实际刷新耗时没下降——大概率是漏了会话级 DML 并行开关。
-
ALTER SESSION ENABLE PARALLEL DML是硬性前提，必须在调用DBMS_MVIEW.REFRESH前执行 - 若使用
ATOMIC_REFRESH => FALSE（推荐），刷新会先 truncate 再 insert，此时并行 insert 才真正生效；设为TRUE（默认）则走 merge，受限更多 - 目标基表（即 MV 查询涉及的表）需已启用并行：检查
user_tables.degree，非1或DEFAULT才有效
如何在 DBMS_MVIEW.REFRESH 中指定并行度？
Oracle 没有直接传入并行度的参数，但可通过组合方式间接控制。核心思路是：让刷新触发的 SQL 走并行执行计划，并确保 DML 阶段能并行写入。
实操建议如下：
- 在刷新前设置会话并行度：
ALTER SESSION SET PARALLEL_DEGREE_POLICY = MANUAL，再执行ALTER SESSION FORCE PARALLEL DML PARALLEL 4 - 对关键基表显式加并行 hint（尤其当统计信息不准导致优化器未选并行时）：
SELECT /*+ PARALLEL(t, 4) */ ... FROM big_table t—— 这个 hint 要写在 MV 定义的 SELECT 中，不是刷新时加 - 避免在刷新语句里用
PARALLELhint：比如DBMS_MVIEW.REFRESH(..., parallelism => 4)是无效的，该参数不存在
哪些系统参数会影响 MV 并行刷新效果？
几个关键参数不配好，等于白开并行。最常被忽略的是 parallel_max_servers 和 parallel_min_servers，它们直接限制实例能分配多少并行进程。
-
parallel_max_servers：必须 ≥ 你期望的总并行度 × 并发刷新任务数。例如单次刷新设PARALLEL 8，又可能有 3 个 MV 同时刷，则至少设为24 -
parallel_adaptive_multi_user：设为FALSE，否则高负载时 Oracle 会自动降级并行度，导致结果不可控 -
parallel_degree_policy：生产环境建议设为MANUAL，避免AUTO模式下优化器擅自改并行度，干扰刷新稳定性 -
resource_manager_plan：如果启用了资源管理计划，确认对应 consumer group 允许使用并行服务器（PARALLEL_SERVER_LIMIT）
为什么有时强制并行反而更慢？
并行不是银弹。当数据倾斜严重、I/O 子系统饱和、或临时表空间争用时，开并行可能放大瓶颈。典型表现是：v$px_session 里大量进程卡在 direct path read temp 或 enq: KO - fast object checkpoint。
- 先确认 I/O 能力：并行度 × 单进程吞吐量不能超过存储带宽。SSD 阵列可撑更高并行，传统 SAS 盘建议 ≤ 4–8
- 检查临时表空间：MV 刷新常依赖
TEMP表空间做排序/哈希，确保其数据文件分散且无争用（查v$sort_usage） - 小数据量 MV 不值得开并行：比如基表总行数
- 用
DBMS_MVIEW.EXPLAIN_MVIEW看刷新计划类型（FAST/COMPLETE）——只有COMPLETE刷新才真正受并行影响；FAST刷新走日志增量，基本不走并行
并行刷新的调试成本其实很高：要同时盯住 v$px_session、v$sysstat（queries parallelized）、v$waitstat 和 AWR 报告里的 Parallel Operations 部分。一个没对齐，就容易误判瓶颈所在。
