Oracle 19c物化视图并行刷新需同时满足三条件：会话级启用PARALLEL DML、atomic_refresh=FALSE、日志支持FAST；缺一即退化串行，且parallelism仅在atomic_refresh=FALSE时生效。
oracle 19c物化视图刷新慢，单纯调大parallelism参数基本无效——真正卡点在会话级并行开关没开、atomic_refresh没关、日志结构不支持fast，三者缺一都会让并行形同虚设。
必须先执行ALTER SESSION ENABLE PARALLEL DML
这是硬性前提，漏掉就全程串行。即使物化视图定义里写了PARTITION BY或基表加了PARALLEL 4，DBMS_MVIEW.REFRESH也不会启用并行DML。
- 执行顺序不能错：必须在
DBMS_MVIEW.REFRESH之前执行该语句，且在同一会话内 - 验证是否生效：刷新期间查
V$PX_SESSION，应看到多个Q00x进程；若只有1个，说明没开成功 - 不要依赖
ALTER SYSTEM全局设置——会话级控制更精准，避免干扰其他作业
atomic_refresh => FALSE和parallelism必须配对使用
parallelism参数本身不控制并行度，它只在atomic_refresh => FALSE时才真正触发分批并行插入。默认TRUE下，所有并行进程挤在一个事务里等提交，锁和undo压力反而更大。
- 推荐值：
parallelism => 2或4，超过CPU_COUNT * 2易引发enq: PS - contention - 副作用：刷新过程中物化视图可能短暂返回新旧混合数据，业务查询需容忍此窗口
- 严禁组合
refresh_after_errors => TRUE——出错跳过批次后，已提交部分无法回滚，状态不可逆
日志结构决定并行是否真能跑FAST刷新
并行只对COMPLETE刷新起作用；而FAST刷新内部由日志驱动，不走并行路径。但如果你以为自己在跑FAST，其实Oracle已静默退化为COMPLETE，那并行参数就完全白配。
- 检查日志是否含
SEQUENCE和PRIMARY_KEY（或ROWID）：执行SELECT SEQUENCE, PRIMARY_KEY FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE' -
INCLUDING NEW VALUES必须存在，否则DELETE和UPDATE变更无法捕获，直接退化 - 多表JOIN时，每个基表都要有独立日志，且
SEQUENCE()中必须包含JOIN列和ROWID
系统级参数不调好，并行会频繁降级
parallel_max_servers设太小，会导致并行进程排队等待；设太大又可能抢占资源。Oracle不会自动帮你平衡，得手动盯住。
-
parallel_max_servers建议 ≥ 单次最大并行度 × 并发刷新任务数（例如刷3个MV，每个设parallelism => 4，至少设为12） -
parallel_adaptive_multi_user必须设为FALSE，否则高负载时Oracle会自动降低并行度，结果不可控 -
parallel_degree_policy设为MANUAL，避免优化器擅自改并行计划，干扰刷新稳定性
最常被忽略的不是参数怎么写，而是日志表MLOG$_xxx本身已经HWM悬空——哪怕SELECT COUNT(*)返回0，dba_segments.bytes可能显示几百MB。不先SHRINK SPACE COMPACT，再大的并行也卡在全表扫描上。
