TRUNCATE基表后FAST刷新必然失败，因TRUNCATE是DDL操作，不写物化视图日志、不推进SCN，导致日志链路断裂；必须用DBMS_MVIEW.REFRESH('YOUR_MV', 'C', atomic_refresh => FALSE)强制全量刷新，否则静默失败或卡死。
TRUNCATE基表后FAST刷新必然失败
因为TRUNCATE是DDL操作，不写物化视图日志（MLOG$），也不推进SCN，FAST刷新依赖的日志链路直接断裂——Oracle根本找不到“自上次刷新以来改了哪些行”，只能退化或卡死。
执行TRUNCATE后必须用COMPLETE+FALSE刷新
别再试method => 'F'，它要么静默失败，要么卡在MERGE INTO MV_NAME不动。真实可用的路径只有一条：
- 先确认物化视图状态：
SELECT staleness, status FROM dba_mviews WHERE mview_name = 'YOUR_MV'，若staleness为STALE或UNUSABLE，说明已不可用 - 强制全量刷新并跳过事务包装：
DBMS_MVIEW.REFRESH('YOUR_MV', 'C', atomic_refresh => FALSE) -
atomic_refresh => FALSE是必须项：否则默认走DELETE + INSERT，大表下undo暴增、锁表时间线性增长；设为FALSE才能触发TRUNCATE + INSERT /*+ APPEND */，把分钟级压到秒级
为什么不能靠FORCE('?')自动兜底
method => '?'（即FORCE）会先试FAST，失败再切COMPLETE，但问题在于：它不报错、不记录原因、也不更新staleness字段。你看到的只是“刷完了”，实际每次都在做全量，而日志缺失、SCN断层、主键变更等真凶始终藏在暗处。
- 典型掩盖场景：基表刚被
TRUNCATE PARTITION，EXPLAIN_MVIEW已显示REFRESH_FROM_LOG_AFTER_ANY = DISABLED，但FORCE仍悄悄走COMPLETE - 后果是资源浪费翻倍、下游感知不到数据延迟、监控告警失灵
重建日志前要先清空MLOG$的HWM悬空
TRUNCATE后即使重建物化视图日志，旧日志表的高水位（HWM）可能仍悬空，导致新日志无法正常捕获变更。这不是权限或语法问题，而是物理存储残留。
- 查HWM是否异常：
SELECT blocks, num_rows, last_analyzed FROM dba_tables WHERE table_name = 'MLOG$_YOUR_TABLE'，若blocks远大于num_rows，说明有空间未回收 - 收缩HWM：
ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT（需启用行移动） - 再
DROP MATERIALIZED VIEW LOG ON your_table，然后重建，确保含INCLUDING NEW VALUES
真正麻烦的不是TRUNCATE本身，而是它让物化视图从“增量可推演”退回到“全量不可信”状态——所有依赖日志时间戳（snaptime$$）、序列号（sequence$$）和行标识（rowid）的机制全部失效，修复必须从物理结构层动手，不能只调参数。
