REFRESH COMPLETE 是 REFRESH FAST 不满足前提时的唯一可行路径；FAST 失败主因是物化视图日志缺失或配置不当、SQL 超出支持场景、基表变更未记录旧新值、嵌套 MV 刷新链中断等硬性条件不满足。
REFRESH COMPLETE 和 REFRESH FAST 不是并列选项，而是有严格前提依赖关系的两种策略：能用 REFRESH FAST 的时候才该选它；不能用时，REFRESH COMPLETE 是唯一可行路径。强行在不满足条件的物化视图上指定 FAST，会直接报错 ORA-12015: cannot create a fast refresh materialized view from a complex query 或类似提示。
为什么 REFRESH FAST 经常失败？关键检查点
REFRESH FAST 不是“开箱即用”的功能，它背后依赖一组硬性条件，漏掉任意一个都会导致刷新失败或退化为全量：
– 基表必须已创建物化视图日志（mlog$_xxx），且日志中包含物化视图 sql 中涉及的所有列（尤其是聚合字段、join 条件列）
– 日志创建时必须带 INCLUDING NEW VALUES 和 WITH PRIMARY KEY（或 WITH ROWID，但主键更稳定）
– 物化视图定义 SQL 必须属于五类支持场景之一：单表非聚合、单表聚合、多表关联、多表关联聚合、UNION ALL
– 如果基表有更新操作，日志里必须同时存在旧值（OLD_NEW$$ = 'O'）和新值（OLD_NEW$$ = 'N'）记录，否则增量逻辑无法还原变更
– 嵌套物化视图中，上游 MV 若被 COMPLETE 刷新过，下游所有依赖它的 MV 在下次 FAST 刷新前，必须先执行一次 COMPLETE —— 否则报 ORA-12047: PCT failure, object is not partition maintained 类错误
REFRESH COMPLETE 看似简单，但空间和锁风险极高
很多人以为 COMPLETE 就是“重跑一遍 SELECT”，实际在 Oracle 中它是原子性重建：先建新段、写入全量数据、再切换指针、最后删旧段。这个过程带来两个真实痛点：
– 全量刷新期间，原物化视图段仍可读，但新段构建需要等价于物化视图数据量的临时空间（比如 MV 有 50GB，临时表空间至少预留 50GB）
– 切换指针瞬间会持有 DDL 锁，若此时有长事务正在查该 MV，可能阻塞数秒甚至更久，尤其在高并发 OLAP 场景下容易引发查询抖动
– 如果物化视图带索引，COMPLETE 会触发全量重建索引（不是 REBUILD，是真正从头建），耗时远超数据写入本身
– 没有“断点续刷”机制：一旦中途失败，整个新段丢弃，下次仍是全量重来
什么时候该用 REFRESH FORCE？它不是兜底方案
REFRESH FORCE 的行为是：先尝试 FAST，失败则自动降级为 COMPLETE。但它掩盖了根本问题：
– 它不会告诉你为什么 FAST 失败，只会静默走全量路径，导致你误判“系统还健康”，实则日志缺失、DML 积压、MV 已滞后数小时
– 在定时任务中滥用 FORCE，可能让某次本该秒级完成的增量，变成占用数 GB 临时空间、持续几分钟的全量，进而拖垮后续调度窗口
– 生产环境建议禁用 FORCE，改用显式脚本：先调 DBMS_MVIEW.EXPLAIN_MVIEW 检查可刷新性，再决定走 FAST 还是人工干预后走 COMPLETE
嵌套物化视图刷新链最容易被忽略的约束
当物化视图 A 作为基表被用于创建物化视图 B 时，A 的刷新方式会直接绑架 B：– 如果 A 被 COMPLETE 刷新过，B 即使定义为 REFRESH FAST ON COMMIT，下一次刷新也必然报错，除非先对 B 手动执行一次 DBMS_MVIEW.REFRESH('B', 'C')
– OceanBase V4.3.5 BP3 起支持单表非聚合的增量，但 Oracle 19c 仍要求所有嵌套层级的 MV 都必须使用主键（不能只靠 ROWID），否则链式刷新中断
– 查看刷新状态不能只看 LAST_REFRESH_DATE，得查 USER_MVIEWS.REFRESH_METHOD 和 USER_MVIEWS.STALENESS，后者为 STALE 表示数据已不可信，哪怕时间戳很新
EXPLAIN_MVIEW 并验证日志内容是否覆盖新增列。 
