刷新卡住时应查dba_jobs、v$session、dba_mviews而非user_mview_analysis；实时进度用v$session_longops配合dbms_application_info打标；dba_mview_logs需与dba_mviews交叉验证。
刷新卡住时，别查 USER_MVIEW_ANALYSIS
这张表默认为空，也不会随 DBMS_MVIEW.REFRESH 自动更新——它只在你手动调用 DBMS_MVIEW.EXPLAIN_MVIEW 或运行 DBMS_STATS.GATHER_SCHEMA_STATS 后才可能填充。查它返回零行，不代表没刷或刷失败，只是没采集过分析数据。
真正该盯的三个视图：DBA_JOBS、V$SESSION、DBA_MVIEWS
物化视图刷新本质是后台作业或会话级操作，状态得从执行层看：
-
DBA_JOBS（12c+ 优先查DBA_SCHEDULER_JOBS）：看BROKEN = 'Y'或NEXT_DATE长期未变，说明调度异常 -
V$SESSION：查PROGRAM LIKE '%mview%'的活跃会话，EVENT若为enq: MV – contention或row cache lock，基本就是锁住了 -
DBA_MVIEWS.STALENESS：值为'STALE'表示需刷新，但不等于失败；'FRESH'也不代表刚刷完——得结合日志增长和会话判断
想跟踪一次刷新的实时进度？用 V$SESSION_LONGOPS
在刷新前给会话打标，才能准确定位：
- 执行刷新前先运行：
DBMS_APPLICATION_INFO.SET_MODULE('MV_REFRESH', 'mv_name') - 再查：
SELECT SID, OPNAME, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100, 1) PCT FROM V$SESSION_LONGOPS WHERE MODULE = 'MV_REFRESH' -
OPNAME通常是Refresh materialized view，SOFAR/TOTALWORK给出估算进度
注意：这个视图只对耗时 > 6 秒的操作自动记录，短平快的 FAST 刷新可能根本不出现在里面。
DBA_MVIEW_LOGS 要配合 DBA_MVIEWS 一起看
单看日志表行数暴涨，不代表刷新滞后——得交叉验证：
- 如果
DBA_MVIEW_LOGS.ROWIDS = 'YES'且LOG_TABLE持续增长，但DBA_MVIEWS.STALENESS = 'FRESH'，可能是用了COMPLETE刷新模式（它不消费日志） - 若
STALENESS = 'STALE'且日志无增长，说明基表 DML 根本没被捕获——检查物化视图日志是否建错、INCLUDING NEW VALUES是否漏了 -
DBA_MVIEW_LOGS中的SNAPTIME$$字段若长期卡在旧时间点，说明刷新进程根本没读取日志
最易忽略的是：刷新不是原子操作，FAST 模式下日志消费和 MV 更新分两步，中间状态会短暂出现“日志积压但 MV 仍 FRESH”的假象。
