Oracle物化视图刷新任务进度与耗时监控

查不到 V$SESSION_LONGOPS 不等于没在刷

很多 DBA 的常规操作是：一遇到物化视图刷新问题，首先就去查询 V$SESSION_LONGOPS。如果该视图为空，心里便开始发慌 ——“是不是刷新根本没启动？” 其实大可不必。Oracle 内部有一条规定：只有执行超过 6 秒、且触发了“长操作注册机制”的步骤才会被记录进去。全表扫描、大排序、并行 DML 等属于“长操作”。但如果物化视图刷新仅处理了少量变更日志，直接从 MLOG$_ 表读取数据，一两秒内完成，那它自然不会进入 longops 的监控范围，这是完全正常的现象。

所以，碰到这种情况，不必急于下结论。以下几个典型的误判场景值得留意：

• 当看到 DBA_MVIEWS.LAST_REFRESH_DATE 未更新，同时 V$SESSION_LONGOPS 返回空时——刷新可能早已静默结束，也可能正卡在某个锁等待或元数据检查阶段，根本没有机会被“注册”为长操作。
• 手动执行 DBMS_MVIEW.REFRESH('MV_NAME','F') 后立刻查询视图——如果变更日志中只有 3 行数据，执行时间不足 1 秒，该视图自然不会出现任何记录。
• 在 opname 字段中搜索不到 Refresh materialized view 关键字——这直接说明当前刷新未走 longops 路径，不必在此继续排查。

换个思路确认：刷新到底在不在跑？卡在哪一步？

物化视图刷新本质上仅是一个后台会话在执行 SQL（无非是 INSERT、MERGE、DELETE），它并非独立服务。因此关键不是寻找“刷新专用视图”，而是精确定位那个会话。

实际操作逻辑如下：

• 使用以下 SQL 定位疑似刷新会话：SELECT sid, serial#, sql_id, event, state FROM V$SESSION WHERE program LIKE '%mview%' OR module LIKE '%DBMS_MVIEW%'。重点确认 state = 'ACTIVE' 且 sql_id 不为空。
• 获取 sql_id 后，查询 V$SQL.sql_text，判断它是在扫描大基表、执行聚合运算，还是向 MV$ 表中写入数据。
• 重点关注 event 字段：db file scattered read 表示正在读取基表数据；enq: TX - row lock contention 说明被其他事务锁定；row cache lock 常见于高并发 DDL 后元数据未及时刷新。

AWR 报告才是判断刷新准时性和耗时的可靠工具

AWR 报告本身并不记录“REFRESH”这个动作——但无需沮丧，它能够还原后台作业（DBMS_SCHEDULER 或 DBMS_JOB）的实际执行时间、能耗及资源消耗。这是判断定时刷新是否按预期发生的唯一可靠方式。

生成 AWR 报告后，重点关注以下三方面：

• 按 CPU 时间排序的 SQL 部分：搜索 DBMS_MVIEW.REFRESH 调用，或匹配 INSERT INTO "MV_NAME"、SELECT FROM "MLOG$_” 等 SQL。这些语句的 executions 次数即为该时段内实际发生的刷新次数。
• 后台进程统计（Instance Activity Stats 下方）：观察 background cpu time 与 background elapsed time 在刷新窗口附近是否突增。数值高说明后台作业运行密集。
• Top 5 等待事件：若 db file sequential read 或 direct path write 在固定整点（如每小时 0 分）集中爆发，则大概率对应着定时刷新任务。

想精确知道某次刷新花了多久、间隔是否稳定？

AWR 是宏观鸟瞰图，如需细粒度记录，应直接查询数据字典。以下 SQL 可直接获取某刷新作业最近 7 天内是否准时、间隔是否稳定：

SELECT job_name, status, actual_start_date, 
       TRUNC((actual_start_date - LAG(actual_start_date) OVER (PARTITION BY job_name ORDER BY actual_start_date)) * 24, 2) AS hours_since_last 
FROM dba_scheduler_job_run_details 
WHERE job_name LIKE '%REFRESH%' 
  AND actual_start_date >= SYSDATE - 7 
ORDER BY actual_start_date DESC;

需要提醒的是：hours_since_last 计算的是实际开始时间之间的间隔，反映作业调度的稳定性，但并不能体现单次刷新内部耗时。若需查看单次耗时，可结合 V$SESSION 中的 logon_time 与 last_call_et，或直接查询 DBA_SCHEDULER_JOB_RUN_DETAILS 中的 actual_start_date 与 actual_end_date 字段。

最后，还有一个真正容易被忽略的陷阱——ON COMMIT 刷新。此类刷新不会出现在调度视图中，因为它绑定在每个事务提交时。此时只能返回查看 Top 5 Timed Foreground Events 中是否有异常的 enq: TX - row lock contention 或 log file sync，这才是判断的硬指标。