应查DBA_JOBS或DBA_SCHEDULER_JOBS获取真实刷新时间，因USER_MVIEW_ANALYSIS仅存手动分析快照，不记录刷新操作；其LAST_REFRESH_DATE等字段非实时刷新时间戳。
直接查 DBA_JOBS 或 DBA_SCHEDULER_JOBS，别碰 USER_MVIEW_ANALYSIS —— 它默认为空，也不记录真实刷新时间。
为什么 USER_MVIEW_ANALYSIS 不能信
这张表不是刷新日志，而是分析结果快照。它只在你显式执行 DBMS_MVIEW.EXPLAIN_MVIEW 或触发统计信息收集后才可能被填充；单独调用 DBMS_MVIEW.REFRESH 不会更新它。常见错误是看到 SELECT * FROM USER_MVIEW_ANALYSIS 返回零行，就以为“没刷新”或“失败”，其实只是压根没采集过指标。
字段如 LAST_REFRESH_DATE 和 STALENESS 来自上次手动分析，不是刷新操作本身的时间戳。
查真实刷新时间：盯住作业调度表
Oracle 的 ON DEMAND 物化视图靠后台作业驱动，时间信息全在作业元数据里：
-
DBA_JOBS（旧版 DBMS_JOB）：看LAST_DATE（最近一次成功执行时间）、NEXT_DATE（下次计划时间）、TOTAL_TIME（单位秒，含历史累计+当前运行时长） -
DBA_SCHEDULER_JOBS（12c+ 推荐）：查LAST_START_DATE、NEXT_RUN_DATE、ELAPSED_TIME（本次运行耗时，格式为+000000000 00:05:23.123456） - 若作业卡住：
BROKEN = 'Y'或LAST_DATE长期未变，说明刷新异常中断
示例（查某 MV 相关作业）：SELECT JOB_NAME, LAST_START_DATE, NEXT_RUN_DATE, ELAPSED_TIME FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME LIKE '%MV_MYDATA%';
查刷新耗时：从会话和作业日志双向验证
单次刷新耗时不能只看作业字段，要结合运行时上下文：
- 正在运行的刷新会出现在
V$SESSION中：PROGRAM含mview，SQL_ID对应实际刷新语句，EVENT常见为enq: MV – contention或row cache lock - 失败刷新必须查
DBA_SCHEDULER_JOB_RUN_DETAILS：STATUS = 'FAILED'+ERROR#（如 12008、60）+ADDITIONAL_INFO（含完整ORA-xxxx和触发语句） -
TOTAL_TIME在DBA_JOBS里是累加值，不等于单次耗时；真正单次耗时得看DBA_SCHEDULER_JOB_RUN_DETAILS的ACTUAL_START_DATE和ACTUAL_END_DATE
示例（查最近 5 次失败）：SELECT log_date, job_name, error#, additional_info FROM DBA_SCHEDULER_JOB_RUN_DETAILS WHERE status = 'FAILED' AND job_name LIKE '%MV_MYDATA%' ORDER BY log_date DESC FETCH FIRST 5 ROWS ONLY;
判断是否真“滞后”：别只看时间，要看状态和日志
刷新时间只是表象，关键看数据是否同步：
-
DBA_MVIEWS.STALENESS字段才是核心指标：值为STALE（需刷新）、FRESH（已同步）、UNUSABLE（损坏） -
DBA_MVIEW_LOGS.LOG_TABLE是否持续增长？如果基表 DML 很多但日志表没变化，说明物化视图日志失效或捕获中断 - 远程 DBLink 不通、基表无主键、物化视图日志缺失——这些建模阶段的问题，往往到刷新失败时才暴露，但根源不在运行时
真正卡住时，优先查 V$SESSION 等待事件和 DBA_SCHEDULER_JOBS 状态，而不是翻空表或猜时间戳。
