必须同时指定 refresh_method => 'COMPLETE' 和 atomic_refresh => FALSE 才能强制全刷：前者无视物化视图日志状态，后者采用 TRUNCATE + INSERT /+ APPEND / 方式避免锁表与 UNDO 问题，确保数据一致。
必须显式指定 refresh_method => 'COMPLETE' 和 atomic_refresh => FALSE，否则所谓“强制刷新”大概率只是走快速路径、静默跳过变更，根本达不到数据一致。
为什么 DBMS_MVIEW.REFRESH('MV_NAME', 'C') 不等于强制全刷
Oracle 的 method => 'C' 仅表示“倾向完全刷新”，但内部仍会检查物化视图日志状态。若日志存在且标记为 VALID，它可能降级为 FAST；若日志损坏或 SCN 错乱（比如分区 EXCHANGE PARTITION 后未同步），反而报 ORA-12006 或漏刷部分分区。
真正绕过所有判断、强制丢弃旧数据重算的，只有两个参数同时生效：
-
refresh_method => 'COMPLETE'：硬开关，无视日志是否存在、是否有效 -
atomic_refresh => FALSE：让刷新变成TRUNCATE + INSERT /*+ APPEND */，避免锁表和大量 UNDO，也规避ORA-01555
分区表场景下最容易踩的坑
基表是范围/列表分区时，执行过 ALTER TABLE ... SPLIT PARTITION 或 EXCHANGE PARTITION 后，物化视图日志里的分区级 SCN 可能滞后，导致 COMPLETE 刷新扫描不到最新数据块——尤其当交换进来的新分区时间戳是未来值（如 2026 年）时，Oracle 会直接跳过该分区。
此时需确认：
- 基表分区键字段未被修改（否则
COMPLETE刷到一半可能报ORA-12008） - 物化视图定义中没用
PARTITION (P1)这类硬编码分区扩展语法（应改用谓词过滤） - 刷新前手动执行
EXEC DBMS_MVIEW.PURGE_LOG('SCOTT', 'T');清理残留日志元数据
调用时 list 参数写法必须精确
哪怕只刷一个物化视图，list 也必须是 'OWNER.MVIEW_NAME' 格式。只写 'MV_NAME' 会因 session 当前 schema 不匹配而报 ORA-00942——这个错误不是物化视图不存在，而是 Oracle 解析元数据失败。
批量刷新时，用逗号拼接：'SCOTT.SALES_MV,HR.EMP_MV'，不能加空格，不能用数组，也不能带 @dblink（跨库刷新必须在目标库本地执行）。
示例正确调用：
EXEC DBMS_MVIEW.REFRESH( list => 'SCOTT.MV_SALES_BY_MONTH', method => 'C', refresh_method => 'COMPLETE', atomic_refresh => FALSE, parallelism => 4 );
真正麻烦的从来不是命令怎么写，而是你刷完之后查出来的数据，到底是不是刚从基表里实时捞出来的那一版——尤其在分区 DDL 操作频繁的系统里，COMPLETE 刷得再快，也可能漏掉刚交换进来的分区数据。
