答案是：last_purge_date停滞超2小时即表明快速刷新已失效，需结合mlog$_表中snaptime$$=date'4000-01-01'的记录数、explain_mview能力报告及基表ddl一致性综合判断；若该字段为空或远滞后，且日志无待消费记录，则日志写入异常，必须重建。
查 dba_mview_logs.last_purge_date 是否停滞
物化视图日志表（mlog$_前缀）里的 last_purge_date 字段，记录的是 oracle 上次从日志中读取并应用变更的时间。如果这个值长期没变（比如停留在 2 天前），哪怕基表持续有 dml，也说明快速刷新已失效——后续 refresh 'f' 很可能直接退化为全量。
执行以下语句确认：
SELECT log_table, last_purge_date, rowids, primary_key FROM DBA_MVIEW_LOGS WHERE master = 'YOUR_BASE_TABLE';
- 若
last_purge_date是空或远早于当前时间（如 >2 小时未更新），优先怀疑日志消费卡住 -
rowids = 'YES'且primary_key = 'NO'：说明日志靠 ROWID 定位变更，但基表发生过 MOVE/SHRINK 等操作后 ROWID 失效，FAST 刷新会静默失败 - 若
last_purge_date正常更新，但 MV 仍滞后，则需进一步查日志内容是否为空
查 MLOG$_ 表里是否有未消费的变更记录
快速刷新依赖日志中存在 SNAPTIME$$ = DATE '4000-01-01' 的记录（表示“待消费”）。如果基表有新 DML，但这条记录数为 0，就说明日志没捕获到变更，FAST 已断链。
运行：
SELECT COUNT(*) FROM MLOG$_YOUR_BASE_TABLE WHERE SNAPTIME$$ = DATE '4000-01-01';
- 结果为 0，且你确认基表近期有 INSERT/UPDATE/DELETE → 日志写入异常（常见于权限丢失、触发器被禁、日志表被 TRUNCATE）
- 结果 >0，但
last_purge_date停滞 → 消费端（即 MV 刷新进程）出问题，可能是锁冲突、事务长时间未提交、或DBMS_MVIEW.REFRESH调用失败后未重试 - 注意：不要直接 SELECT * 查 MLOG$_ 表，大日志表容易拖慢性能；COUNT 带 WHERE 条件是安全的
用 EXPLAIN_MVIEW 看关键能力是否 DISABLED
DBMS_MVIEW.EXPLAIN_MVIEW 的输出比错误信息更早暴露 FAST 刷新不可用的本质原因。重点关注 CAPABILITY_NAME 字段的状态：
SELECT capability_name, possible, msgtxt
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'BASIC'))
WHERE capability_name IN ('REFRESH_FAST_PCT', 'REFRESH_FROM_LOG_AFTER_INSERT');
实际执行应为：
BEGIN DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME'); END;
然后查 MV_CAPABILITIES_TABLE（需提前创建）：
SELECT capability_name, possible, msgtxt FROM MV_CAPABILITIES_TABLE WHERE mvname = 'YOUR_MV_NAME';
-
REFRESH_FAST_PCT = DISABLED：分区变更跟踪（EUT）未启用，或当前用户无SELECT_CATALOG_ROLE -
REFRESH_FROM_LOG_AFTER_INSERT = DISABLED：日志缺少必要列（如 GROUP BY 字段未包含在日志定义中） -
possible = 'UNKNOWN'不代表“可能”，而是权限不足或内部元数据不一致，等同于 DISABLED - 即使所有项都标
POSSIBLE，只要last_purge_date停滞或日志为空，FAST 仍会 fallback 到 COMPLETE
确认基表是否发生过破坏日志结构的 DDL
Oracle 不会在基表 DDL 后自动同步或重建物化视图日志。一次 ALTER TABLE ... MODIFY COLUMN 或 DROP PRIMARY KEY 就可能导致日志与基表脱钩，而系统不会报错，只在下次刷新时静默失败。
- 对比基表和日志的
OBJECT_ID：SELECT object_id FROM DBA_OBJECTS WHERE object_name = 'YOUR_BASE_TABLE'vsSELECT master_object_id FROM DBA_MVIEW_LOGS WHERE log_table = 'MLOG$_YOUR_BASE_TABLE'—— 不一致即脱钩 - 检查
msgtxt中是否含"materialized view log is invalid"或"base table DDL changed" - 最直接验证：对基表做一条 INSERT，再查 MLOG$_ 表是否多了一行
SNAPTIME$$ = DATE '4000-01-01'；没有 → 日志已失效，必须重建
需要重新全量刷新，往往不是因为“数据不准”，而是增量路径已经彻底中断。真正棘手的点在于：Oracle 很少主动报错，它更倾向静默降级——REFRESH 'F' 返回成功，但背后跑的是 COMPLETE，且不告诉你为什么。所以不能只看刷新是否成功，得盯住日志状态、能力报告、DDL 变更这三块，缺一不可。
