物化视图COMPLETE刷新卡在TRUNCATE或INSERT/+ APPEND /阶段，主因是锁等待、HWM残留、统计信息失效致执行计划错误；应检查阻塞会话、收集统计信息、收缩表空间、设atomic_refresh=>FALSE、避免外键与函数索引、优化并行及CLOB处理，并确认_mv_refresh_use_stats为TRUE。
物化视图 COMPLETE 刷新卡在 TRUNCATE 或 INSERT /*+ APPEND */ 阶段？
根本原因往往不是 SQL 本身慢，而是底层对象锁、高水位线（HWM）残留或统计信息失效导致优化器选错执行计划。比如 TRUNCATE 在有未提交事务或依赖物化视图日志的基表上会等待，而 INSERT /*+ APPEND */ 若目标表存在大量空闲块或未分析，可能退化为常规插入，甚至触发大量回滚段写入。
实操建议：
- 刷新前用
SELECT * FROM V$SESSION WHERE BLOCKING_SESSION IS NOT NULL检查是否有阻塞会话 - 确认基表和物化视图表都已执行
DBMS_STATS.GATHER_TABLE_STATS，尤其注意ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE - 若表曾频繁
DELETE但未SHRINK SPACE，执行ALTER TABLE ... SHRINK SPACE COMPACT再刷新，可显著减少APPEND的物理写开销
DBMS_MVIEW.REFRESH 调用时没指定 atomic_refresh => FALSE
默认值是 TRUE，意味着整个刷新过程在一个事务里完成：先 TRUNCATE，再 INSERT，失败则全部回滚。这不仅放大锁持有时间，还强制写大量 undo 和 redo —— 即使只刷新几百万行，也可能因日志切换或归档压力拖慢数倍。
实操建议：
- 对非关键报表类物化视图，显式传参：
atomic_refresh => FALSE，此时 Oracle 改用TRUNCATE+INSERT /*+ APPEND */分离操作，不生成 undo，也不受事务隔离影响 - 注意前提：目标表不能有启用的外键约束（否则
TRUNCATE报ORA-02266），也不能有基于函数的索引（APPEND可能报ORA-12838） - 配合
parallel => TRUE使用时，必须同时设atomic_refresh => FALSE，否则并行无效
基表含大字段（CLOB/BLOB）或未分区，且物化视图定义含聚合
完全刷新会重跑整个 SELECT 子句。如果基表是单一大分区表、含未压缩 CLOB 字段，或聚合涉及 GROUP BY + 多列 SUM/COUNT，Oracle 可能无法有效利用并行，反而因中间结果集膨胀撑爆 TEMP 表空间或触发磁盘排序。
实操建议：
- 检查执行计划中是否出现
TEMP TABLE TRANSFORMATION或大量SPILL TO TEMP，若有，优先增大PGA_AGGREGATE_TARGET（非临时方案） - 对含
CLOB的场景，考虑改用DBMS_LOB.SUBSTR截断或在物化视图定义中排除该字段（如业务允许） - 若基表支持分区，把物化视图建在分区键上，并启用
ENABLE QUERY REWRITE，后续可转向快速刷新（FAST）替代COMPLETE
数据库参数 _mv_refresh_use_stats 被禁用或统计不准
该隐含参数控制物化视图刷新时是否参考基表统计信息来估算中间结果集大小。默认开启（TRUE），但如果被手动设为 FALSE，或统计信息过期严重，Oracle 可能低估数据量，分配过小的内存/并行度，最终退化为串行处理加多次磁盘扫描。
实操建议：
- 查当前值：
SELECT KSPPINM, KSPPSTVL FROM X$KSPPSV WHERE KSPPINM = '_mv_refresh_use_stats'，确保返回TRUE - 不要依赖自动收集任务——对核心基表，每天凌晨刷新后立即运行
DBMS_STATS.GATHER_TABLE_STATS，并指定cascade => TRUE同步索引统计 - 若仍慢，可临时加 hint 强制并行：
/*+ PARALLEL(t, 4) */写进物化视图定义的 SELECT 中（需重建）
真正耗时的从来不是“刷新”这个动作，而是你没看见的锁等待、统计偏差和隐式降级。别急着调大并行度，先看 V$SESSION_LONGOPS 里卡在哪一步，再对照 V$SQL_PLAN 确认实际执行路径——很多所谓“慢刷新”，本质是计划崩了，不是数据多了。
