COMPLETE刷新在大数据量下特别慢，因其默认ATOMIC_REFRESH=TRUE走临时表+原子替换路径，导致LOB数据全量写入UNDO、锁表时间长、并发阻塞；改用ATOMIC_REFRESH=FALSE可提速3–5倍，但需规避聚合/连接且确保表空间连续空闲。

COMPLETE刷新为什么在大数据量下特别慢

因为complete刷新本质是truncate + insert /*+ append */，但oracle默认走的是atomic_refresh => true路径：先建临时表、全量插入、再原子替换。这会导致整个lob或大字段数据一次性加载进undo段，极易触发ora-01555，同时锁表时间长、并发阻塞严重。

• 基表有LOB列时，即使没显式SELECT，只要物化视图定义含CLOB/BLOB列，内部就会启用物理复制路径，跳过SQL层优化
• 未指定PARALLELISM时，默认串行执行，无法利用多CPU资源
• DBMS_MVIEW.REFRESH不校验目标表空间空闲区大小，若空闲区碎片化严重，直接路径写入会频繁等待分配新区

用ATOMIC_REFRESH => FALSE绕过UNDO瓶颈

设为FALSE后，刷新改走TRUNCATE + 直接路径INSERT /*+ APPEND */，完全跳过UNDO生成，速度提升3–5倍，但要求业务能容忍短暂不可用窗口（TRUNCATE期间查询报ORA-08103）。

• 必须确保物化视图不含聚合、连接、子查询——否则ATOMIC_REFRESH => FALSE会被忽略，悄悄退回到默认行为
• 执行前确认目标表空间有足够连续空闲区：SELECT tablespace_name, bytes/1024/1024 MB FROM dba_free_space WHERE tablespace_name = 'YOUR_TS' ORDER BY bytes DESC
• 示例调用：DBMS_MVIEW.REFRESH('MV_SALES_DETAIL', method => 'C', atomic_refresh => FALSE, parallelism => 8)

并行度parallelism不是越大越好

parallelism值超过PARALLEL_MAX_SERVERS或Undo表空间数据文件数，反而引发争用。实测中，值设为4–8最稳，再高收益递减，且易触发ORA-12853（insufficient parallel query slaves）。

• 检查当前限制：SHOW PARAMETER parallel_max_servers 和 SELECT COUNT(*) FROM dba_data_files WHERE tablespace_name = (SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE')
• 若物化视图含SECUREFILE LOB，parallelism > 1会自动启用LOB并行加载，但需确保CHUNK大小一致（查USER_LOBS.chunk），否则部分LOB为空
• 避免在高峰时段设高并行——它会抢占大量PGA，影响其他会话

LOB列让COMPLETE刷新隐式变重

哪怕只是定义里带一个CLOB列，COMPLETE刷新就不再走普通INSERT逻辑，而是调用底层LOB copy机制。此时MAXSIZE不匹配会静默截断，SECUREFILE属性不一致则报ORA-00942或跳过该列。

• 创建物化视图时显式指定存储参数：LOB (doc_content) STORE AS SECUREFILE (CHUNK 8192)，与源表严格对齐
• 权限必须直接授予：GRANT SELECT ON source_table TO mv_owner，不能通过角色继承，否则刷新时读不到LOB locator
• 如果LOB非核心字段，最有效方案是剥离：把物化视图拆成两个——一个无LOB的主MV（FAST可刷），一个按需关联的LOB视图（SELECT * FROM lob_table WHERE id IN (SELECT id FROM mv_main)）

真正卡住COMPLETE刷新的，往往不是SQL本身，而是LOB存储配置、并行资源争用和UNDO路径选择。这些细节不手动核对，调参再多也白搭。