complete刷新适用于跨数据库链接访问远程表、源表结构频繁变更、物化视图含复杂sql、基表无物化视图日志或日志缺失关键字段、数据量不大的场景。
COMPLETE刷新适合哪些场景
当物化视图跨数据库链接（@dblink）访问远程表时，COMPLETE是唯一可用选项——FAST会直接报ORA-12015或ORA-12008，连语法校验都过不去。这不是配置问题，而是Oracle内核限制：物化视图日志（MLOG$）必须建在基表所在库，本地MV进程无法读取远程日志。
以下情况也建议强制用COMPLETE：
- 源表结构频繁变更（如加列、改类型），而物化视图未设
ON PREBUILT TABLE，否则查询可能返回旧字段或报错 - 物化视图定义含复杂SQL（如多层嵌套、分析函数、非确定性函数
SYS_GUID()），FAST不支持 - 基表没建物化视图日志，或日志缺失
ROWID、SEQUENCE等关键字段 - 数据量不大（
FAST刷新的硬性前提条件
FAST不是“开了就行”，它依赖一套严格对齐的基础设施：
- 基表必须存在物化视图日志：
CREATE MATERIALIZED VIEW LOG ON t WITH ROWID, SEQUENCE (col1,col2) INCLUDING NEW VALUES - 物化视图定义中不能出现
SELECT *、子查询、UNION、CONNECT BY等不支持增量计算的结构 - 所有参与JOIN的基表都需有对应日志，且日志字段覆盖SELECT列表中的列
- 创建时显式指定
REFRESH FAST ON DEMAND或ON COMMIT，不能只写FORCE
漏掉任一条件，DBMS_MVIEW.EXPLAIN_MVIEW会返回capable\_yes = 'F'，但实际刷新时才暴露失败——别等调度任务跑崩了再查。
FORCE模式到底靠不靠谱
FORCE看似省心，实则埋雷：
- 它先尝试
FAST，失败后自动降级为COMPLETE，但这个“失败”可能发生在执行中（比如日志损坏、空间不足），导致刷新耗时陡增且不可预测 - 跨库场景下
FORCE等价于COMPLETE，因为FAST路径根本不可达，徒增一层判断开销 - 监控时难区分是正常
FAST还是兜底COMPLETE，日志里只记refresh_type='F'，容易掩盖真实瓶颈
生产环境建议显式写死REFRESH COMPLETE或REFRESH FAST，避免行为黑盒。
刷新性能差异的真实影响点
很多人只盯着“全量 vs 增量”，却忽略真正卡脖子的环节：
-
COMPLETE的耗时主要由远程查询响应时间、网络带宽、结果集大小决定，和本地IO关系不大；而FAST的瓶颈常在日志表锁争用或MV$回放SQL的执行计划劣化 - 同库
FAST刷新通常比COMPLETE快一个数量级，但跨库时COMPLETE反而更稳——没有日志同步失败、无须处理DBLINK超时重试逻辑 -
ON COMMIT刷新虽实时，但会拖慢基表DML事务；ON DEMAND可控，但需配DBMS_SCHEDULER作业，且跨库必须用ON DEMAND（ON COMMIT不支持远程基表）
最易被忽略的是：跨库物化视图即使设了REFRESH COMPLETE ON DEMAND，也必须确保DBLINK权限双向精确（源库用户要有SELECT，目标库用户要有CREATE SESSION），否则DBMS_MVIEW.REFRESH调用静默失败，查USER_JOBS也看不到错误。
