Oracle 19c物化视图刷新太慢如何诊断_检查刷新作业状态

物化视图刷新慢？先别急着看执行计划，按这个顺序排查更高效

物化视图刷新慢应先查v$session_longops确认是否卡住，再验证LAST_REFRESH_DATE、LAST_PURGE_DATE及手动C模式刷新，最后检查DB Link和BUILT_STATUS是否有效。

第一步：查物化视图刷新是否卡在 longops 里

遇到物化视图刷新慢，第一反应往往是想看执行计划。但更高效的做法，是先确认这个刷新任务到底有没有“卡住”。Oracle会把那些长时间运行的操作——比如物化视图刷新——记录在 v$session_longops 动态视图中。只要操作没超时、没报错，就可能一直挂在这里，造成“慢”的假象。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

执行下面这个查询，可以快速定位问题：

SELECT sid, serial#, opname, target, sofar, totalwork,
        ROUND(sofar/NULLIF(totalwork,0)*100,2) pct_done,
       elapsed_seconds, sql_id
FROM v$session_longops WHERE opname LIKE '%refresh%'
   AND totalwork > 0
   AND sofar < totalwork;

查询结果通常能看出几种典型情况：

• opname 显示为 Refresh materialized view，但 pct_done（完成百分比）长时间不动。这往往意味着刷新过程被阻塞了，或者基表被锁住了。
• sql_id 为空。这说明刷新操作可能还没真正生成执行SQL，而是卡在了前期的元数据检查或读取物化视图日志的阶段。
• elapsed_seconds（已运行秒数）远超历史平均水平。比如平时刷新只要2分钟，这次却跑了20分钟还没完。这时就需要根据这个 sql_id 去进一步查看真实的执行计划了。

第二步：用 DBMS_MVIEW.EXPLAIN_MVIEW 先验判断能否快刷

别等到调用 DBMS_MVIEW.REFRESH 跑半天，才发现它实际上在做全量（complete）刷新。很多“慢”的本质，是本来应该走快速（fast）刷新，却因为某些条件不满足，被迫退化成了全量刷新。而 DBMS_MVIEW.EXPLAIN_MVIEW 这个工具，能在真正执行刷新前，就帮你把根本原因暴露出来。

执行命令后，查看 MVIEW_EXCEPTIONS 表或直接看输出：

EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_SALES_SUMMARY');

重点关注输出结果中 MSGTXT 字段的提示，它们基本就是性能瓶颈的定位器：

• 出现 "REFRESH FAST IS NOT POSSIBLE"：这通常意味着缺少物化视图日志，或者基表没有主键，或者创建的日志没包含 ROWIDS 选项。
• 出现 "NO LOG ON BASE TABLE"：这更直接，说明基表压根就没创建物化视图日志，很可能当初建MV时漏掉了 CREATE MATERIALIZED VIEW LOG ON ... 这一步。
• 显示 "POTENTIAL FAST REFRESH" 但实际刷新没用上：这可能是因为物化视图日志里没有未消费的变更（检查 LAST_PURGE_DATE 是否很久没更新），或者基表DML操作后没有提交。

有一点需要特别注意：EXPLAIN_MVIEW 只验证定义层面的可行性，不检查网络、权限等运行时问题。如果它说“可以快刷”，但实际刷新仍然很慢，那么问题大概率出在运行时环节，比如日志数据积压过多、相关索引缺失，或者遇到了锁等待。

第三步：检查刷新作业是否被其他 job 或 session 阻塞

物化视图的定时刷新通常通过 DBMS_JOB 或 DBMS_SCHEDULER 来调度。一旦底层的作业被卡住，后续的刷新任务就会全部排队。尤其是当多个物化视图属于同一个刷新组时，只要其中一个卡住，整个组都可能停摆。

首先，看看当前有没有正在运行的刷新作业：

SELECT job_name, state, last_start_date, running_instance
FROM dba_scheduler_jobs WHERE job_name LIKE '%MV%' OR job_action LIKE '%REFRESH%';

接着，检查是否有会话在等待锁资源：

SELECT blocking_session, sid, serial#, event, sql_id
FROM v$session WHERE event LIKE 'enq:%' OR event LIKE 'library cache%';

这个环节要特别留意几种情况：

• 如果 blocking_session 指向另一个 DBMS_MVIEW.REFRESH 会话：这说明刷新组正在串行执行，需要确认业务上是否真的需要这种强一致性。
• 如果 event 显示为 enq: TX - row lock contention：这通常意味着基表正在被业务上的DML操作修改，刷新进程在等待那个事务提交。
• 如果定时任务用的是 DBMS_REFRESH.REFRESH，其默认参数 ATOMIC_REFRESH => TRUE 会导致刷新时锁住整个组的所有表。将其改为对单个MV刷新，并设置 ATOMIC_REFRESH => FALSE，往往可以绕过这个问题。

第四步：确认刷新是否真的在跑，还是“静默跳过”了

调用 DBMS_MVIEW.REFRESH 过程返回“成功”，并不代表数据真的被更新了。尤其是在使用 method => 'F'（快速刷新）模式时，如果物化视图日志为空、没有新变更、或者权限失效，这个过程可能什么都不做就直接返回SUCCESS，给人一种“刷新很快”的错觉。

因此，需要验证以下三件事：

• 查看 USER_MVIEWS.LAST_REFRESH_DATE 是否更新：如果这个时间戳没变，说明刚才的刷新调用根本没生效。
• 查看 USER_MVIEW_LOGS.LAST_PURGE_DATE：如果这个时间远早于当前时间，说明物化视图日志里的变更记录一直没有被消费掉。可能是上次刷新失败后，系统没有自动重试。
• 手动触发一次 method => 'C'（完全刷新）：如果强制全量刷新能刷出新数据，那么之前 F 模式的问题，100%出在日志或变更捕获环节。这就不是性能问题了，而是刷新逻辑链断了。

这里有一个最容易被忽略的坑：对于跨数据库的物化视图（依赖DB Link），当数据库链接失效时，EXPLAIN_MVIEW 可能不报错，但 REFRESH 却会静默失败。所以，务必检查 DBA_MVIEWS.BUILT_STATUS 和 DBA_MVIEW_LOGS 相关状态字段是否为 VALID。