物化视图快速刷新失败主因是降级为全量刷新后卡死，需查MVIEW_REFRESH_TIMES、SNAPTIME$$时间戳、MLOG$数据量及日志定义完整性，再结合EXPLAIN_MVIEW与MVIEW_EXCEPTIONS定位根本原因。
先确认是不是根本没走快速刷新
很多“刷新失败”其实是 DBMS_MVIEW.REFRESH 悄悄降级成 COMPLETE 后卡住，但没报错。查 DBA_MVIEW_REFRESH_TIMES 或直接看物化视图最后刷新时间是否长期停滞，再比对 LAST_REFRESH_DATE + increfreshtim/86400（单位秒）是否远小于当前时间——如果是，说明增量部分根本没执行成功，FORCE 已 fallback 到全量，而全量因数据量大或锁表卡死。
用 DBMS_MVIEW.EXPLAIN_MVIEW 查真实支持状态：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('your_mv_name');然后查
MVIEW_EXCEPTIONS 表，重点看 RECOMMENDATION 字段。出现 QSM-01106 且 RECOMMENDATION 是 AGGREGATE 或 JOIN，就不是日志问题，是定义本身不满足 FAST 条件。
物化视图日志表 MLOG$_xxx 数据暴涨但没被消费
这是典型“有日志、无消费”信号。执行：
SELECT COUNT(*) FROM mlog$_your_master_table;
如果结果远大于日常 DML 量（比如百万级），且
DBA_BASE_TABLE_MVIEWS 中对应 MVIEW_LAST_REFRESH_TIME 是陈旧时间，基本可断定刷新任务已中断或失败多次被标记为 BROKEN。
- 先查自动任务状态：
SELECT job, broken, failures, next_date FROM user_jobs WHERE what LIKE '%your_mv_name%';—— 若BROKEN = 'Y'且NEXT_DATE = DATE '4000-01-01'，说明任务已被 Oracle 自动禁用 - 不要直接
DROP MATERIALIZED VIEW LOG，这会清空所有未消费日志，影响其他复用该日志的物化视图 - 若确认该日志仅被单个 MV 使用，可用
TRUNCATE TABLE mlog$_your_master_table;清空内容，保留结构 - 清理后必须立刻手动执行一次
DBMS_MVIEW.REFRESH，否则日志不会重新开始记录新变更
分区表 + 快速刷新时 SNAPTIME$$ 时间戳错位
Oracle 不支持按分区名直接刷新，而是靠 SNAPTIME$$ 和日志中的 SEQUENCE$$ 排序间接控制。如果基表做了大量批量导入或 INSERT /*+ APPEND */，可能跳过日志记录，或导致 SNAPTIME$$ 滞后于实际提交时间。
- 查日志最新时间戳：
SELECT MAX(snaptime$$) FROM mlog$_your_master_table;，对比当前系统时间，若差值超过UNDO_RETENTION（如差 30 分钟，而undo_retention=900），后续FAST刷新大概率报ORA-01555 - 避免在高并发时段执行刷新，尤其当基表有
ON COMMIT刷新依赖时，事务提交延迟会导致SNAPTIME$$批量堆积 - 对超大分区，改用
ATOMIC_REFRESH => FALSE：它绕过事务包装，直接TRUNCATE + INSERT /*+ APPEND */，缩短一致性读窗口，但 MV 在刷新中会短暂为空
最易被忽略的点：物化视图日志列缺失与 INCLUDING NEW VALUES
即使建了日志，如果没包含物化视图 SQL 中所有 SELECT 的列，或漏了 INCLUDING NEW VALUES，FAST 就会静默失效。
- 检查日志定义：
SELECT master, log_table, rowids, primary_key, filter_columns, sequence FROM user_mview_logs WHERE master = 'YOUR_MASTER_TABLE'; -
ROWIDS = 'YES'是必须的；SEQUENCE = 'YES'不能少；FILTER_COLUMNS应列出 MV 查询中所有字段（不能是表达式，如UPPER(name)） -
INCLUDING NEW VALUES缺失会导致 INSERT 不被捕获——现象是 MV 里永远看不到新插入的数据，只更新旧行 - 重建日志前，先确认是否有其他 MV 正在使用它（查
USER_REGISTERED_MVIEWS），避免误伤
真正卡住的地方往往不在错误信息里，而在日志表里那几行 snaptime$$ 和 sequence$$ 的值是否连续、是否被截断、是否和其他 MV 共享却没人清理。别急着重刷，先盯住 mlog$_xxx 的数据增长节奏和时间戳分布。
