物化视图数据与基表不一致是刷新机制失效的明确信号，根源在于fast刷新静默降级为complete、物化视图日志与基表结构脱节、mv定义含非确定性元素或人工干预破坏刷新链路。
物化视图数据与基表不一致，不是“偶发异常”，而是刷新机制失效的明确信号——它已经静默发生了，只是你还没查。
快速刷新（FAST）实际没生效，却误以为在跑增量
这是最常见也最危险的情况。你建了 REFRESH FAST ON COMMIT，但 Oracle 在内部检测到日志损坏、主键变更、新增 NOT NULL 列未同步进日志、或聚合列含 NULL 未被 SEQUENCE 覆盖时，会自动降级为 COMPLETE 刷新，且不报错、不告警。
-
DBA_MVIEWS.STALENESS显示STALE或UNUSABLE，但REFRESH_METHOD字段仍可能显示FAST—— 这是元数据缓存假象，真实执行路径已切走 - 查
V$MVREFRESH中最近一次刷新的REFRESH_METHOD和ATOMIC_REFRESH值，比看定义更可信 - 如果基表做过
ALTER TABLE ... ADD COLUMN ... DEFAULT，但没重建物化视图日志，MLOG$_表里就缺该列，FAST 必然断链
物化视图日志（MLOG$）状态与实际基表结构脱节
日志不是“活”的，它是建表那一刻的快照。基表主键删了又加、分区做了 EXCHANGE、字段类型隐式转换（比如 NUMBER 改成 NUMBER(10,2)），都会让日志元数据失效，而 Oracle 不主动校验。
- 执行
SELECT PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，若返回Y但基表已无主键约束 → 日志不可用 -
DBMS_MVIEW.EXPLAIN_MVIEW返回MSGNO = 2005（“no materialized view log with primary key”）是硬性拒绝信号 - 分区表做
MOVE PARTITION后，日志里的SNAPTIME$$可能没更新，导致COMPLETE刷新漏读刚移入的数据块
物化视图定义本身引入不确定性
只要 SQL 里出现非确定性元素，FAST 就注定失败，且错误常被掩在 ORA-12008 下层。
-
SYSDATE、USER、ROWNUM、DBMS_RANDOM.VALUE等函数会让物化视图无法做行级变更映射 -
AVG()或SUM()直接作用于允许 NULL 的列，而日志未启用INCLUDING NEW VALUES→ NULL 变更不被捕获，聚合结果停滞 - 使用了
DISTINCT、ROLLUP、窗口函数或ORDER BY，这些在 Oracle 19c 的 FAST 刷新中明确不支持
人工干预破坏了刷新链路完整性
运维过程中几个看似无害的操作，实则直接切断增量路径。
- 手动
UPDATE MLOG$_xxx SET SNAPTIME$$ = ...—— 时间戳错乱后，Oracle 认为“该刷的都刷过了”，跳过后续变更 - 用
TRUNCATE TABLE清空基表后没重建日志，或清空了MLOG$_表但没重置SNAPTIME$$ - 多个物化视图共用一个日志，其中一个重建日志时没通知其他 MV，导致部分 MV 刷新报
ORA-12052
真正棘手的从来不是“怎么重刷”，而是“为什么上次没刷对”。所有不一致背后，都有日志状态、基表结构、MV 定义三者之间至少一处未对齐。盯住 DBA_MVIEW_LOGS、DBA_MVIEWS 和 V$MVREFRESH 这三张表，比反复执行 DBMS_MVIEW.REFRESH 有效得多。
