必须显式指定refresh_method => 'COMPLETE'和atomic_refresh => FALSE才能真正强制全量刷新，否则即使传'C'仍可能因日志状态有效而降级为FAST，导致静默不一致或失败。
直接用 dbms_mview.refresh 触发全量同步，不等于真正执行了全量——默认参数下它仍可能悄悄走快速刷新（fast），尤其当日志表存在但已损坏时，结果是卡住、报错或静默跳过数据。必须显式关闭快速路径，否则“重试”只是重复失败。
为什么 EXEC DBMS_MVIEW.REFRESH('MV_NAME', 'C') 不一定全量刷新
Oracle 的 method => 'C' 只是“建议”走 COMPLETE，但底层会先检查物化视图日志（MLOG$_*）是否可用、是否有未消费记录。若日志状态为 VALID 且有积压变更，它仍会降级为 FAST 刷新，而非重建全量数据。
-
refresh_method => 'COMPLETE'是硬开关，强制忽略日志，丢弃旧数据后重新执行定义查询 -
atomic_refresh => FALSE让刷新变成TRUNCATE + INSERT /*+ APPEND */，避免 DELETE 带来的锁和 undo 压力 - 只传
'C'不加这两个参数，在分区表、日志错位、基表刚做过EXCHANGE PARTITION的场景下大概率失败或漏数据
调用前必须确认的三件事
盲目执行刷新可能让问题恶化：锁表、日志暴涨、甚至把物化视图刷成空表（atomic_refresh => FALSE 失败时无回滚）。
- 查日志是否完整：
SELECT LOG_TABLE, ROWIDS, SEQUENCE FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_MASTER_TABLE'。若SEQUENCE = 'NO'或关键字段缺失，FAST 必不可用，此时refresh_method => 'COMPLETE'是唯一出路 - 看物化视图当前状态：
SELECT STALENESS, LAST_REFRESH_DATE, REFRESH_METHOD FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_NAME'。如果STALENESS = 'UNUSABLE'或'COMPILATION_ERROR'，先解决编译问题（如基表 DDL 变更未同步），再刷新 - 确认不是只读库：
SELECT OPEN_MODE FROM V$DATABASE。备库上atomic_refresh => FALSE会直接报ORA-16000，只能切到快照备用库或改用主库刷新
DBMS_MVIEW.REFRESH 全量调用的正确写法
以下调用才能确保真正丢弃旧数据、全量重建，且兼顾性能与可控性：
EXEC DBMS_MVIEW.REFRESH( list => 'MV_SALES_BY_MONTH', method => 'C', refresh_method => 'COMPLETE', atomic_refresh => FALSE, parallelism => 4 );
-
parallelism建议设为 2–8，避免过高并发压垮 I/O；对超大表可配合/*+ PARALLEL(t,4) */在物化视图定义查询中显式提示 - 不要省略
list参数用字符串数组批量刷新——单个 MV 刷新失败会导致整批中断，应逐个调用、单独捕获异常 - 执行后立刻查
DBA_MVIEW_REFRESH_TIMES确认FULLREFRESHTIM > 0且LAST_REFRESH_DATE更新，否则说明没真正走 COMPLETE 路径
分区表场景下容易被忽略的陷阱
基表是分区表时，COMPLETE 刷新仍可能漏数据，尤其在做过 ALTER TABLE ... SPLIT PARTITION 或 EXCHANGE PARTITION 后。
- 物化视图日志的
SNAPTIME$$字段不会自动更新分区级 SCN，导致刷新扫描高水位块时跳过刚交换进来的分区数据 - 若物化视图定义含分区扩展语法（如
SELECT * FROM T PARTITION (P2024)），需确认该分区名在刷新时刻真实存在，否则报ORA-12008 - 最稳妥做法：刷新前手动清空日志（
TRUNCATE TABLE mlog$_your_master_table），再立即执行上述全量调用，确保从干净起点重建
真正难的不是写对那几行 PL/SQL，而是判断「此刻到底该不该全量」——日志是否可信、基表结构是否漂移、分区状态是否一致，这些信息都藏在 DBA_MVIEW_LOGS、DBA_MVIEWS 和 MLOG$_* 表里，而不是错误堆栈中。
