分区删除后物化视图FAST刷新必然失效，因DDL不写入MLOG$日志，Oracle无法构造增量delta，报ORA-12052并静默降级；必须手动执行COMPLETE刷新才能恢复数据一致性。
分区删除后物化视图不会自动同步，必须手动触发刷新，且默认 REFRESH FAST 会失败——因为被删分区对应的变更日志（MLOG$ 表）里已无对应记录，Oracle 无法构造增量 delta。
为什么 REFRESH FAST 在分区删除后失效
物化视图的 FAST 刷新依赖源表物化视图日志（MLOG$_xxx）中记录的 DML 变更。但 ALTER TABLE ... DROP PARTITION 是 DDL 操作，不写入物化视图日志，也不触发 ON COMMIT 刷新逻辑。日志里只存 INSERT/UPDATE/DELETE，没有 DROP PARTITION 的痕迹。
此时执行 DBMS_MVIEW.REFRESH('mv_name', 'F')，Oracle 检测到基表结构变化（分区数减少）+ 日志缺失对应快照，直接报 ORA-12052: cannot fast refresh materialized view，并静默退回到 COMPLETE 模式（除非显式指定 FAST 并开启 FORCE）。
- 即使日志存在，只要分区被删，
MLOG$表中该分区旧数据已清空或不可见，FAST 无法定位“上次刷新后新增/修改了哪些行” -
REFRESH FORCE会先尝试 FAST，失败后自动走 COMPLETE，但你不会在日志里看到明确提示，只发现耗时陡增 - 如果物化视图定义里用了
WHERE过滤条件（如WHERE dt >= TRUNC(SYSDATE - 7)），而被删分区恰好覆盖这部分时间范围，FAST 更可能因谓词失配失败
REFRESH COMPLETE 是唯一可靠选择
分区删除属于结构性变更，同步必须重算全量结果集。不能依赖增量，必须接受一次完整重建。
- 执行前确认目标物化视图未被锁定：
SELECT * FROM dba_mviews WHERE mview_name = 'YOUR_MV';查LAST_REFRESH_DATE和STALENESS（应为UNUSABLE或STALE） - 用
DBMS_MVIEW.REFRESH显式指定'C'：EXEC DBMS_MVIEW.REFRESH('YOUR_MV', 'C'); - 大数据量时加
PARALLELISM参数提速：BEGIN DBMS_MVIEW.REFRESH('YOUR_MV', 'C', PARALLELISM => 4); END; - 若物化视图建在
ON PREBUILT TABLE上，COMPLETE刷新会 TRUNCATE + INSERT APPEND，比普通 INSERT 快；但需确保目标表上无触发器或约束冲突
如何避免下次再踩坑
分区管理与物化视图必须联动设计，不能孤立操作。
- 删分区前，先手动刷新一次物化视图（
REFRESH FAST或COMPLETE），确保状态干净；再删分区；最后再刷一次COMPLETE - 对高频分区维护的表，考虑改用
REFRESH ON DEMAND+ 调度脚本，在分区操作后自动补刷，而不是依赖ON COMMIT - 不要在物化视图 SQL 中硬编码分区键值（如
WHERE part_col IN ('P202401', 'P202402')），应使用函数或绑定变量，否则分区删掉后查询直接报错 - 监控
V$MVIEWS的STALENESS字段，UNUSABLE状态说明物化视图已与基表结构不兼容，必须COMPLETE刷新才能恢复
真正麻烦的不是刷新本身，而是分区删完才发现物化视图查出来数据少了一块——因为 FAST 静默降级没报警，COMPLETE 又没及时跑。生产环境建议把分区 DDL 和 MV 刷新打包成原子脚本，删分区和刷 MV 绑定执行。
