查不到v$session_longops不表示刷新未进行,因该视图仅记录超6秒且触发长操作机制的步骤;物化视图刷新若处理少量变更或直接读mlog$_表,根本不会进入此路径。

查不到 V$SESSION_LONGOPS 就代表没在刷新?
不是。该视图只记录执行超 6 秒、且触发 Oracle 长操作注册机制的步骤(比如全表扫描、大排序),而物化视图刷新若只处理几行变更、或直接读 MLOG$_ 表,根本不会进入这个视图——它压根没走到 longops 路径。
常见误判场景:
-
DBA_MVIEWS.LAST_REFRESH_DATE没更新,但V$SESSION_LONGOPS返回空 → 刷新可能早结束了,也可能卡在锁等待或元数据检查阶段 - 手动执行
DBMS_MVIEW.REFRESH('MV_NAME', 'F')后立刻查V$SESSION_LONGOPS→ 若日志里只有 3 行变更,执行时间不到 1 秒,自然不出现opname - 查不到
Refresh materialized view→ 说明当前刷新没走 longops 路径,别在这儿死磕
怎么确认刷新任务真在跑、卡在哪一步?
刷新本质是后台会话在执行 SQL(INSERT、MERGE、DELETE),不是独立服务。关键不是找“刷新专用视图”,而是定位这个会话。
实操建议:
- 用
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 报告后,盯这三处:
-
SQL ordered by CPU Time:搜索含
DBMS_MVIEW.REFRESH字样的调用(注意大小写),或匹配INSERT INTO "MV_NAME"、SELECT FROM "MLOG$_的语句;这些 SQL 的executions次数就是该时段内实际刷新发生次数 -
Background Processes(在 Instance Activity Stats 下方):查看
background cpu time和background elapsed time是否在刷新窗口附近突增;高值说明后台作业密集运行 -
Top 5 Timed Events:若
db file sequential read或direct path write在固定整点(如每小时 0 分)集中爆发,大概率对应定时刷新任务
查作业执行统计比翻 AWR 更快
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;
注意:
- 若刷新由
ON COMMIT触发,则根本不会走后台作业——必须看Top 5 Timed Foreground Events是否出现异常的enq: TX - row lock contention或log file sync -
DBA_SCHEDULER_JOB_LOG比DBA_JOBS更可靠,尤其在 12c+ 环境下;老版本 Oracle(如 10g)的DBMS_JOB可能不完整计入 AWR -
DBA_MVIEWS.STALENESS字段才是判断是否真“滞后”的核心依据:STALE表示需刷新,FRESH表示已同步,UNUSABLE表示结构损坏
刷新状态判断真正依赖的是组合信号:作业是否调度成功、会话是否活跃、等待事件是否异常、STALENESS 是否为 STALE、以及日志表 DBA_MVIEW_LOGS.LOG_TABLE 行数是否持续增长——单看一个指标很容易误判。











