Oracle物化视图自动刷新“假成功”指作业执行成功但实际降级为COMPLETE刷新，根本原因是运行时动态检查失败后静默fallback；关键判断依据是DBA_MVIEWS.FAST_REFRESHABLE='NO'，常见诱因包括日志未捕获变更、调度器配置错误、跨DB Link限制或基表DDL导致编译失效。

自动刷新不是“配完就跑”，而是多个环节松耦合协作，任一环节卡住都会导致偶发失败，且 Oracle 往往不报错、只静默降级或跳过。

DBA_MVIEWS.FAST_REFRESHABLE = 'NO' 却没报错

这是最典型的“假成功”场景：调度作业执行了，日志里也显示“completed”，但物化视图实际走的是 COMPLETE 刷新。根本原因是 Oracle 在运行时动态检查失败后直接 fallback，不抛异常。

• 查 DBA_MVIEWS.FAST_REFRESHABLE 字段，值为 'NO' 就说明快速刷新不可用——哪怕你写了 REFRESH FAST ON DEMAND
• 常见诱因：MLOG$_<table> 日志表里没有新记录（<code>SELECT COUNT(*) FROM MLOG$_sales 返回 0），说明基表变更未被捕获
• SNAPTIME$$ 字段仍为 01-JAN-4000，表示日志从未被消费，刷新只是空转

DBMS_SCHEDULER 作业看似在跑，其实没触发刷新逻辑

很多人误以为 START WITH SYSDATE NEXT SYSDATE+1/24 这种写法能定时刷新，但它只是把语句存进数据字典，根本不会创建可执行的后台任务。

• 必须用 DBMS_SCHEDULER.CREATE_JOB 显式创建 job，且 job_action 要完整包裹 PL/SQL 块，例如：BEGIN DBMS_MVIEW.REFRESH('mv_sales', 'F'); END;
• 漏掉 ENABLE => TRUE 参数，job 默认是 DISABLED 状态，永远不执行
• 如果 job 所用用户缺少 CREATE JOB 或 EXECUTE ANY PROCEDURE 权限，作业会静默失败（查 DBA_SCHEDULER_JOB_LOG 可见 STATUS = 'FAILED'）

跨 DB Link 或基表结构变更引发隐式失效

这类问题最难排查，因为刷新失败往往延迟出现，且错误信息不指向根源。

• 跨 DB Link 的物化视图，REFRESH FAST 直接不可用，Oracle 不提示，只退化为 COMPLETE；若远程库版本低（如 Oracle 10g）、或 DB Link 用户密码过期，连 COMPLETE 都会报 ORA-02068 或 ORA-01017
• 基表执行了 ALTER TABLE ... DROP COLUMN，会导致 DBA_MVIEWS.COMPILE_STATE = 'INVALID'，此时即使手动调用 REFRESH 也会失败，必须先 ALTER MATERIALIZED VIEW mv_name COMPILE，甚至重定义
• 多表连接 MV 中某张基表新增了外键约束但没建索引，UPDATE 操作可能因锁升级卡住，表现为刷新长时间无响应，v$locked_object 显示 MLOG$_<table> 被持锁 <p>真正麻烦的不是报错，而是所有环节都“看起来正常”：作业状态 OK、日志表有数据、<code>STALENESS 显示 'STALE'——但 LAST_REFRESH_DATE 几天没变，FAST_REFRESHABLE 是 'NO'，而你还在查网络或磁盘空间。