parallelism > 1 会强制启用并行dml和lob直写路径；只要parallelism设为大于1且atomic_refresh=>false，oracle即启用并行dml并自动切换至物理lob复制路径，绕过sql层优化，直接分块加载lob数据至pga缓冲区。
parallelism > 1 会强制启用并行DML和LOB直写路径
只要 parallelism 设为大于 1，且 atomic_refresh => FALSE，Oracle 就会启用并行 DML（需先执行 ALTER SESSION ENABLE PARALLEL DML）。此时，哪怕物化视图 SQL 里只带一个 CLOB 或 BLOB 列（哪怕基表有、MV 定义里没显式选），Oracle 也会自动切换到物理 LOB 复制路径——这条路径完全绕过 SQL 层优化，所有 LOB 数据直接进 PGA 缓冲区做分块加载，不走常规 INSERT 的内存管理逻辑。
常见错误现象：刷新时 v$pgastat 显示 total PGA allocated 短时飙升，v$session 中对应会话的 pga_used_mem 达数 GB，同时出现大量 direct path write temp 和 sort segment 等待。
LOB CHUNK 大小不一致导致 PGA 冗余分配
当物化视图含 SECUREFILE LOB 且 parallelism > 1，Oracle 启用 LOB 并行加载，但要求所有 LOB 列的 CHUNK 大小必须一致。查法：SELECT chunk FROM user_lobs WHERE table_name = 'YOUR_MV_TABLE'。
- 若 CHUNK 不一致（比如有的 8K、有的 16K），Oracle 会按最大 CHUNK 分配缓冲区，造成 PGA 浪费
- 部分 LOB 写入失败或为空，日志中可能无报错，只在查询时暴露数据缺失
- 即使 MV 定义里没显式 SELECT LOB 列，只要基表有 LOB 且 MV 查询覆盖该表（如
SELECT *），就触发该路径
并行度超过系统资源上限引发 PGA 抢占
parallelism 值不是线性提升效率，而是成倍放大单会话 PGA 占用。它受两个硬限制制约：
-
PARALLEL_MAX_SERVERS：查法SHOW PARAMETER parallel_max_servers；超限直接报ORA-12853 - UNDO 表空间数据文件数：影响并行写入的并发通道数，查法
SELECT COUNT(*) FROM dba_data_files WHERE tablespace_name = (SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE')
实测中，设 parallelism => 16 往往比 8 多耗 2.3 倍 PGA，但刷新耗时仅快 8%，其余时间全卡在 enq: PV - contention 和 PGA memory not large enough 类等待上。
ATOMIC_REFRESH => FALSE 下的 INSERT /*+ APPEND */ 本身就要大 PGA
设 atomic_refresh => FALSE 后，刷新退化为 TRUNCATE + INSERT /*+ APPEND */，而 /*+ APPEND */ 模式依赖 PGA 中的直接路径缓冲区来攒批写入。这个缓冲区大小由 _smu_debug_mode 和隐含参数 _serial_direct_read 间接影响，无法通过 pga_aggregate_target 直接控制。
容易被忽略的一点是：哪怕没有 LOB，只要目标表空间空闲区碎片化严重（查 dba_free_space 中连续 bytes 小于 1MB 的记录过多），Oracle 会频繁重分配新区，每次分配都额外申请 PGA 缓冲区，形成“小写多配”的恶性循环。
