LAST_REFRESH_DATE未更新但刷新无报错，通常是DBLINK断开、调度任务BROKEN或物化视图元数据失效所致；需查USER_SCHEDULER_JOB_LOG、验证DBLINK连通性、检查BROKEN状态及STALENESS，并针对性修复。
LAST_REFRESH_DATE没变，但执行DBMS_MVIEW.REFRESH没报错
这几乎肯定不是“刷新卡住”，而是 oracle 主动跳过了本次刷新，且不抛错、不写日志。常见于 dblink 断开：你执行 exec dbms_mview.refresh('mv_name', 'f') 返回成功，但 last_refresh_date 和 last_refresh_end_time 完全没更新——因为底层根本没连上远端库，直接静默退出。
真实失败记录只藏在 USER_SCHEDULER_JOB_LOG 里，且 STATUS 字段常为 FAILED 而非 ERROR，监控脚本若只查 ERROR 就会漏掉；DBA_MVIEW_REFRESH_LOGS 和告警日志（alert.log）里什么都不会有。
- 先查
SELECT * FROM USER_SCHEDULER_JOB_LOG WHERE JOB_NAME LIKE '%MV%' ORDER BY LOG_DATE DESC FETCH FIRST 5 ROWS ONLY - 再确认 DBLINK 是否真通：
SELECT * FROM DUAL@your_dblink—— 别只信DBA_DB_LINKS里显示“存在” -
DBMS_MVIEW.REFRESH没有任何重试参数，refresh_after_errors对 DBLINK 失联完全无效
LAST_REFRESH_DATE停在某时刻，自动刷新任务却还在跑
如果物化视图是定时刷新（比如用 DBMS_REFRESH 或 Scheduler Job），LAST_REFRESH_DATE 长期不动，大概率是调度任务已被标记为 BROKEN。典型表现是 NEXT_DATE 变成 4000-01-01，FAILURES > 0，BROKEN = 'Y'。
Oracle 默认失败 16 次就自动禁用任务，但不会通知你。手动执行 DBMS_MVIEW.REFRESH 成功，只是绕过了坏掉的调度器，不代表自动刷新已恢复。
- 查任务状态：
SELECT job, broken, failures, next_date FROM user_jobs WHERE what LIKE '%MV_NAME%' - 修复不能只改
NEXT_DATE，必须先DBMS_JOB.BROKEN(job_id, FALSE)再COMMIT - 更推荐迁移到
DBMS_SCHEDULER，它的日志和错误可见性远高于DBMS_JOB
手动刷新后 LAST_REFRESH_DATE 更新了，但数据还是旧的
这是事务隔离导致的“假象”。默认 ATOMIC_REFRESH => TRUE 时，整个刷新在一个事务内完成，期间物化视图不可读——你查到的仍是刷新前的快照，甚至可能被阻塞住。
设成 ATOMIC_REFRESH => FALSE 后，会先 TRUNCATE 再 INSERT，中间存在空窗期：如果你恰在 TRUNCATE 后、INSERT 前查询，看到的是空结果，而非“旧数据”，容易误判为刷新失败。
- 确认是否真执行了：看
LAST_REFRESH_END_TIME是否更新，别只信 PL/SQL 的 success 返回 - 查
USER_MVIEWS.STALENESS：如果是STALE但LAST_REFRESH_END_TIME已更新，说明刷新完成但数据未生效（如权限不足、基表变更未同步） - 用
SELECT * FROM mlog$_base_table WHERE snaptime$$ > SYSDATE - 1看日志是否有新记录，判断增量是否被捕获
分区表修改后 LAST_REFRESH_DATE 不再更新
对基表做 ALTER TABLE ... ADD PARTITION 或 EXCHANGE PARTITION 后，物化视图元数据可能失效，STALENESS 变成 UNUSABLE 或 NEEDS_COMPILE，此时即使调度任务正常运行，刷新也会被跳过，LAST_REFRESH_DATE 就停摆。
关键点在于：分区操作本身不触发日志记录，如果没启用 INCLUDING NEW VALUES，批量导入或分区交换的数据就进不了物化视图日志，FAST 刷新直接判定失败，降级逻辑也不一定触发。
- 先查状态：
SELECT mview_name, staleness, compile_state FROM dba_mviews WHERE mview_name = 'YOUR_MV_NAME' - 若为
NEEDS_COMPILE，必须先ALTER MATERIALIZED VIEW your_mv_name COMPILE - 若日志缺失
SEQUENCE或ROWID，重建日志：CREATE MATERIALIZED VIEW LOG ON base_table WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES - 注意：基表
ALTER TABLE DROP COLUMN后，日志不会自动更新，必须重建
真正难排查的，是那些既不报错、也不更新时间戳的“静默失效”——DBLINK 断开、调度任务被拉黑、元数据失效，三者都表现为 LAST_REFRESH_DATE 停摆，但根因完全不同。查日志表、看调度状态、验 DBLINK 连通性，缺一不可。
