强制全量刷新需同时指定refresh_method => 'complete'和atomic_refresh => false，前者禁用快速路径，后者触发truncate+insert以绕过日志依赖并提升性能。
物化视图与分区表基表数据不一致时，dbms_mview.refresh 默认可能走快速刷新（fast），而快速刷新依赖物化视图日志和内部状态判断——一旦日志损坏、时间戳错乱或分区 ddl 操作（如 alter table ... split partition）未被正确捕获，就会跳过变更，导致静默不一致。此时「强制全量刷新」是最直接可控的修复手段。
如何触发真正意义上的全量刷新（非原子 + 完全）
Oracle 的 REFRESH 有多个参数组合，容易误以为 DBMS_MVIEW.REFRESH('MV_NAME', 'C') 就是“完全刷新”，但实际是否执行全量，还取决于物化视图定义中是否含 REFRESH FAST ON COMMIT 或日志是否存在。必须显式禁用快速路径：
- 使用
atomic_refresh => FALSE：绕过事务原子性，直接 truncate + insert，避免 UNDO 压力和锁等待 - 搭配
refresh_method => 'COMPLETE'：明确拒绝 FAST，强制重建全量结果集 - 若物化视图基于分区表且含分区扩展语法（如
SELECT * FROM T PARTITION (P1)），需确认基表分区键未被修改，否则COMPLETE可能报ORA-12008: error in materialized view refresh path
示例调用：
EXEC DBMS_MVIEW.REFRESH( list => 'MV_SALES_BY_MONTH', method => 'C', atomic_refresh => FALSE, refresh_method => 'COMPLETE' );
为什么不能只用 REFRESH('C')？
单纯传 'C'（即 method => 'C'）在多数情况下仍会尝试走快速刷新逻辑，尤其当物化视图日志存在且状态为 VALID 时。Oracle 内部会检查 MLOG$_* 表中是否有未处理记录，若有，则自动降级为 FAST；若日志已损坏或缺失关键字段（如 SNAPTIME$$ 被人工改过），反而可能报 ORA-12006: cannot create prebuilt materialized view 或静默跳过部分分区。
-
refresh_method => 'COMPLETE'是硬开关，无视日志状态，强制丢弃旧数据 -
atomic_refresh => FALSE关键在于它让刷新过程变成 DDL 级操作（TRUNCATE+INSERT /*+ APPEND */），比默认的DELETE+INSERT快一个数量级，且不生成大量 REDO - 注意：该组合要求物化视图无 ON COMMIT 刷新依赖，且调用用户有
ALTER ANY MATERIALIZED VIEW权限
分区表场景下容易被忽略的陷阱
当基表是范围/列表分区且做了 EXCHANGE PARTITION 或 MOVE PARTITION 后，物化视图日志可能未同步更新分区级 SCN，导致 COMPLETE 刷新时扫描到错误的高水位块，漏读刚交换进来的数据。
- 刷新前先执行
DBMS_MVIEW.REFRESH_DEPENDENT检查依赖链是否断裂，重点关注ALL_MVIEWS中STALENESS字段是否为UNUSABLE或NEEDS_COMPILE - 若基表最近执行过
ALTER TABLE ... MODIFY PARTITION ... UPDATE INDEXES，需确保物化视图所依赖的本地索引也处于 VALID 状态，否则COMPLETE刷新可能因索引不可用而失败 - 对大型分区表，建议在
refresh_method => 'COMPLETE'前手动收集基表统计信息（DBMS_STATS.GATHER_TABLE_STATS），避免优化器误选嵌套循环连接导致刷新超时
强制全量刷新不是“重跑一遍 SQL”那么简单——它绕过了 Oracle 对变更的智能判断，但也放弃了增量能力。真正棘手的 case 往往藏在分区边界和日志 SCN 的微小偏移里，动手前务必确认 MLOG$_* 表里没有残留的 OLD_NEW$$ = 'O' 记录，否则即使全刷完，下次快速刷新仍可能复现不一致。
