complete刷新撑爆undo表空间是因为atomic_refresh=true时走建临时表+全量insert路径，lob/clob等大字段全部写入undo；设为false后改用truncate+append，跳过undo生成，但要求物化视图无聚合、连接或子查询，且调用时必须显式传参。
为什么COMPLETE刷新会撑爆UNDO表空间
因为默认ATOMIC_REFRESH => TRUE，Oracle走的是「建临时表 + 全量INSERT」路径，所有LOB/CLOB列数据、大字段、甚至未显式SELECT的隐式LOB列，都会被完整写入UNDO段。百万级数据一刷，UNDO瞬间暴涨，极易触发ORA-01555或ORA-30036。
必须关掉ATOMIC_REFRESH才能绕过UNDO瓶颈
设为FALSE后，刷新变成TRUNCATE + 直接路径INSERT /*+ APPEND */，完全跳过UNDO生成，速度提升3–5倍，UNDO压力归零。但有硬性前提：
- 物化视图定义不能含聚合（
SUM、COUNT等）、连接（JOIN）、子查询——否则Oracle会悄悄忽略该参数，退回默认行为 - 业务需容忍刷新窗口期：
TRUNCATE执行瞬间物化视图为空，查询会报ORA-08103（对象不存在） - 调用时必须显式传参：
DBMS_MVIEW.REFRESH('MV_NAME', method => 'C', atomic_refresh => FALSE)，定时任务里不能依赖默认值
并行度不是越大越好，反而容易引发新问题
parallelism设太高，会抢光PGA、压垮UNDO回滚段，甚至触发ORA-12853（并行slaves不足）。实测稳定区间是4–8：
- 先查上限：
SHOW PARAMETER parallel_max_servers，再查UNDO表空间数据文件数：SELECT COUNT(*) FROM dba_data_files WHERE tablespace_name = (SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE') - 若物化视图含
SECUREFILE LOB，并行启用LOB并行加载，但要求CHUNK大小一致（查USER_LOBS.chunk），否则部分LOB为空 - 避免在业务高峰设高并行——它不只抢CPU，更吃PGA内存，会拖慢其他会话
LOB列是隐形放大器，哪怕只定义没用也逃不掉
只要物化视图SQL里包含任何CLOB/BLOB列（哪怕只是SELECT *带出来的），Oracle就自动启用物理LOB复制路径，彻底绕过SQL层优化，UNDO开销翻倍。解决办法很直接：
- 重构物化视图，显式列出非LOB字段，避开LOB列
- 若必须保留LOB，确认目标表空间有足够连续空闲区：
SELECT tablespace_name, bytes/1024/1024 MB FROM dba_free_space WHERE tablespace_name = 'YOUR_TS' ORDER BY bytes DESC，碎片化严重会导致直接路径写入频繁等待分配新区 - 别指望
ATOMIC_REFRESH => FALSE能救LOB-heavy场景——它只跳过事务日志，LOB copy本身仍要消耗大量PGA和临时空间
atomic_refresh => FALSE。这两点漏掉一个，UNDO就照涨不误。
