refresh on demand 是默认模式，需显式调用才刷新，不自动监听查询；fast 刷新失败可能静默降级为 complete，须查 can_use_log 和 mlog$_xxx 表确认；定时刷新依赖 job_queue_processes > 0 且非受限会话。
REFRESH ON DEMAND 是默认模式，但必须显式调用才能生效
创建时没写 ON COMMIT，Oracle 就自动设为 ON DEMAND —— 这不等于“自动按需”，而是“完全不自动”。它只表示：刷新时机由你控制，不是数据库替你决定。
常见误解是以为 ON DEMAND 会监听查询、触发懒加载式刷新。实际上，它什么也不监听，MV 数据 stale 就一直 stale，直到你手动执行刷新命令。
-
DBMS_MVIEW.REFRESH('mv_name', 'F')：尝试快速刷新（F），失败则报错，不会 fallback -
DBMS_MVIEW.REFRESH('mv_name', 'C')：强制完全刷新（C），清空重算 -
DBMS_MVIEW.REFRESH('mv_name', 'F')传错大小写（如'f'）会报 ORA-04021 - 多 MV 批量刷新用逗号分隔名：
DBMS_MVIEW.REFRESH('mv1,mv2,mv3', 'F')
REFRESH FAST 失败却不报错？检查 CAN_USE_LOG 和日志消费状态
执行 DBMS_MVIEW.REFRESH 返回成功，不代表真走了增量路径。Oracle 在 FAST 条件不满足时，会静默降级为 COMPLETE 刷新，且不抛异常 —— 只在元数据里改标记。
真正判断依据只有两个：
- 查
DBA_MVIEWS.CAN_USE_LOG：值为'NO'表示日志未被识别或字段不匹配 - 查
MLOG$_xxx表中未被消费的记录：SELECT COUNT(*) FROM MLOG$_emp WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_EMP_DEPT')，结果 > 0 说明日志堆积，FAST 实际未生效 - 日志表里
SEQUENCE$$最大值远大于SNAPTIME$$对应的序列，也说明刷新没真正消费日志
定时按需刷新必须配 job，NEXT 不等于调度器
NEXT TRUNC(SYSDATE) + 1 这类表达式只是告诉 Oracle “下次该算啥时候”，本身不启动任何任务。背后依赖的是 Oracle 的旧式 job 队列机制，极易失效。
-
job_queue_processes必须 > 0（12c+ 建议 ≥ 1000），否则 job 全部挂起 - 数据库不能处于
RESTRICTED SESSION模式（SELECT LOGGED_ON FROM V$SESSION可查） - 执行
SELECT WHAT FROM DBA_JOBS WHERE WHAT LIKE '%DBMS_MVIEW.REFRESH%'，无结果说明定时注册根本没成功 -
START WITH和NEXT必须是 DATE 类型表达式，写成'SYSDATE + 1'（字符串）直接导致 ORA-12012
权限和上下文常被忽略：刷新失败未必是语法问题
即使 SQL 语法全对、日志齐全、定时配置无误，刷新仍可能失败，原因往往出在运行上下文。
- MV 所有者必须对每个基表有
SELECT权限（不是SELECT ANY TABLE） - 需具备
CREATE JOB权限（12c+ 默认不授予普通用户） - 若 MV 含 DB Link，远程库连接必须可用，且 DB Link 用户密码未过期
- 刷新过程不输出错误日志，默认 silent fail；加
ATOMIC_REFRESH => FALSE参数可减少锁等待，但不解决权限问题
最易漏的一点：物化视图日志里的 INCLUDING NEW VALUES 缺失时，UPDATE 场景下旧值丢失，FAST 刷新会 silently 产生脏数据，而非报错中断。
