必须先建物化视图日志且类型匹配刷新方式，否则dbms_mview.refresh执行fast会报ora-12004或ora-12034；日志需含snaptime$$字段并启用时间戳模式，建时须明确不指定commit scn，且including new values不可省略，否则update/delete无法捕获导致fast失败。
必须先建物化视图日志，且日志类型要匹配刷新方式；否则 dbms_mview.refresh 执行 fast 会直接报 ora-12004 或 ora-12034。
物化视图日志必须显式创建并含 SNAPTIME$$ 字段
基于时间戳的增量刷新（即传统 FAST）依赖 MLOG$_xxx 表里的 SNAPTIME$$ 字段来标记“上次刷新点”。这个字段不会自动出现——你得在建日志时明确不指定 COMMIT SCN，Oracle 才会启用时间戳模式。
常见错误现象：CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY; 看似合法，但如果后续物化视图定义里用了分析函数、外连接或未包含所有主键列，FAST 刷新仍会退化为 COMPLETE，且不报错，只在 DBA_MVIEWS 中把 FAST_REFRESHABLE 设为 NO。
实操建议：
- 建日志时用
INCLUDING NEW VALUES（尤其涉及UPDATE场景），否则旧值丢失会导致FAST失败 - 确认基表有主键或唯一约束，且日志声明了
PRIMARY KEY或ROWID；混合使用会触发隐式转换，导致日志写入异常 - 执行
SELECT * FROM MLOG$_t WHERE SNAPTIME$$ = TO_DATE('4000-01-01', 'YYYY-MM-DD')，若返回空，说明日志未被 MV 刷新机制识别
DBMS_MVIEW.REFRESH 的 FAST 模式实际生效条件极苛刻
即使日志存在、字段齐全，FAST 也不一定真走增量路径。Oracle 在每次刷新前会检查物化视图定义是否满足“可快速刷新”（fast refreshable）语义规则，一旦不满足就静默降级为 COMPLETE。
典型不满足场景：
- 物化视图 SQL 中含
SYSDATE、ROWNUM、子查询中的聚合 + 分析函数嵌套 - 基表被
TRUNCATE过：这会清空MLOG$_xxx，但SNAPTIME$$不重置，导致下次FAST试图读“不存在的变更”，直接报ORA-12034 - 多个物化视图共享同一张基表日志，但其中某个 MV 定义里漏了日志中声明的列（比如日志含
INCLUDING NEW VALUES，而 MV 查询只选了旧值列）
验证是否真走增量：刷新后立刻查 SELECT COUNT(*) FROM MLOG$_t WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_T')。非零才说明有增量数据被消费。
时间戳刷新链断裂后必须人工干预 SNAPTIME$$
SNAPTIME$$ 是物化视图自己的“水位线”，不是全局时钟。如果刷新失败（如网络中断、目标库宕机）、或手动执行了 ALTER MATERIALIZED VIEW ... REFRESH COMPLETE，这个字段不会自动更新，后续 FAST 就永远卡在旧时间点，持续重复消费同一段日志，甚至引发主键冲突。
修复方法不是重跑 REFRESH FAST，而是强制推进水位：
- 先停掉所有依赖该日志的刷新任务（
DBMS_JOB.REMOVE或禁用调度器 JOB） - 用
DBMS_MVIEW.REFRESH带ATOMIC_REFRESH => FALSE强制一次FAST，观察是否成功 - 若仍失败，直接更新日志表：
UPDATE MLOG$_t SET SNAPTIME$$ = SYSDATE WHERE SNAPTIME$$ = TO_DATE('4000-01-01', 'YYYY-MM-DD');，再COMMIT—— 但这相当于丢弃所有未消费变更，仅适用于测试或低一致性要求场景
更稳妥的做法是：定期用 SELECT MVIEW_NAME, LAST_REFRESH_DATE, STALENESS FROM DBA_MVIEWS 监控 STALENESS 是否为 STALE 或 UNUSABLE，早于问题爆发前介入。
RAC 环境下时间戳刷新需统一节点时钟且禁用本地临时对象
时间戳依赖系统时间做比较，RAC 各节点若时钟漂移超过 1 秒，SNAPTIME$$ 就会出现跨节点不一致：节点 A 刷到 T1，节点 B 却因时间慢，把 T1 之后的变更误判为“已刷过”，跳过写入日志，导致数据丢失。
此外，任何在刷新过程中创建的 GLOBAL TEMPORARY TABLE 或调用 UTL_FILE 写本地文件的操作，在 RAC 下都不可靠——任务可能在任意节点执行，而临时表/路径未必存在。
实操建议：
- 强制 NTP 同步所有 RAC 节点，监控
ntpq -p输出的 offset 值，确保 - 刷新逻辑里彻底避免
CREATE GLOBAL TEMPORARY TABLE；改用会话级 PL/SQL 集合（TYPE t_tab IS TABLE OF ...）暂存中间结果 - 日志路径类操作全部改为
DBMS_SCHEDULER作业 + 统一挂载的 ASM 磁盘组，而非本地/tmp
最易被忽略的一点：SNAPTIME$$ 字段本身没有索引，当 MLOG$_xxx 表积累数百万行后，FAST 刷新的 WHERE 条件（SNAPTIME$$ ）会全表扫描日志表——性能断崖下跌。此时必须手工加索引：<code>CREATE INDEX idx_mlog_snaptime ON MLOG$_t(SNAPTIME$$) NOLOGGING;，且定期 ANALYZE TABLE MLOG$_t COMPUTE STATISTICS 更新统计信息。
