物化视图刷新卡住时应先查v$session和v$sql定位执行会话及sql，再结合v$session_longops看进度；dba_mview_logs和dba_mview_refresh_times仅反映历史状态，不表实时进展。
物化视图刷新卡住了？先查 v$session 和 v$sql
oracle 不提供开箱即用的“刷新进度条”，但刷新本质是执行 sql（如 insert / merge / delete），所以它一定跑在某个会话里。关键不是找“刷新专用视图”，而是定位这个会话。
常见错误现象：执行 DBMS_MVIEW.REFRESH 后长时间无响应，DBA_MVIEWS.LAST_REFRESH_DATE 没更新，但又没报错。
- 用
SELECT sid, serial#, sql_id, event, state FROM V$SESSION WHERE program LIKE '%mview%' OR module LIKE '%DBMS_MVIEW%';找出疑似刷新会话 - 拿到
sql_id后查SELECT sql_text FROM V$SQL WHERE sql_id = 'xxx';，确认是不是正在执行大表扫描或聚合 - 注意
event字段：如果是db file scattered read或direct path read，说明在读基表；如果是enq: TX - row lock contention，大概率被锁住了
DBA_MVIEW_LOGS 和 DBA_MVIEW_REFRESH_TIMES 能告诉你什么
这两个视图不反映实时进度，但能帮你判断“为什么刷得慢”或“是不是根本没启动”。它们记录的是历史行为和日志状态，不是运行时快照。
-
DBA_MVIEW_LOGS关注LOG_TABLE和ROWIDS：如果日志表本身有大量未消费的变更（SELECT COUNT(*) FROM <log_table>;</log_table>），全量刷新可能被拖累，快速刷新也可能因日志膨胀变慢 -
DBA_MVIEW_REFRESH_TIMES的LAST_REFRESH_DATE是上一次完成时间，不是当前开始时间；若该字段长期不更新，说明刷新失败或卡死，需结合V$SESSION_LONGOPS - 注意：
DBA_MVIEW_REFRESH_TIMES只记录成功完成的刷新，中途中断不会写入
真正能看“进度”的是 V$SESSION_LONGOPS
这是最接近“进度条”的视图，但前提是刷新操作触发了 Oracle 的 long operation 机制（比如走全表扫描、大排序、并行 DML）。简单单行 UPDATE 不会出现在这里。
- 执行
SELECT opname, target, sofar, totalwork, units, elapsed_seconds, time_remaining FROM V$SESSION_LONGOPS WHERE sofar != totalwork AND time_remaining > 0; -
opname值为Table Scan、Sort Output、Group By Sort等才代表正在干活；若查不到结果，说明当前刷新没进入 longops 范围（比如只刷新几条记录） -
time_remaining是估算值，波动大，尤其当执行计划中途切换或统计信息过期时，别太当真 - 必须关联
V$SESSION看SID，否则不知道是哪个物化视图在刷
刷新卡死时，别只盯着物化视图本身
实际排查中，80% 的“刷新不动”问题跟基表有关：锁、统计信息陈旧、并行度失控、甚至空间不足。物化视图只是受害者。
- 检查基表是否有长事务未提交：
SELECT * FROM V$LOCKED_OBJECT a, DBA_OBJECTS b WHERE a.OBJECT_ID = b.OBJECT_ID; - 确认基表统计信息是否 7 天内更新过：
SELECT last_analyzed FROM DBA_TABLES WHERE table_name = '<base_table>';</base_table>，过期统计常导致优化器选错执行计划，把FAST REFRESH变成全扫 - 如果用了
ATOMIC_REFRESH => FALSE，刷新前会 truncate，此时检查DBA_SEGMENTS中物化视图段是否被锁住（truncate 需要排他锁） - 并行刷新（
PARALLELISM > 1）可能耗尽PARALLEL_MAX_SERVERS，查V$PX_SESSION看有没有挂起的并行进程
监控本身不难，难的是意识到：物化视图刷新没有独立生命周期，它完全寄生在底层 SQL 和实例资源上。盯着 DBA_MVIEWS 刷新时间字段，不如直接看会话在干什么。
