awr不直接记录物化视图刷新频率，但可通过dbms_scheduler作业执行时间、后台进程活动及递归sql（如mlog$扫描、insert/update）精准还原实际刷新行为。
awr 本身不直接记录“物化视图刷新频率”，但能准确还原后台作业（如 dbms_scheduler 或 dbms_job）的执行时间、耗时和资源消耗——这才是判断实际刷新是否按预期发生的唯一可靠方式。
查不到“REFRESH”动作？先确认它是不是真在 AWR 里
物化视图刷新本身不会作为独立 SQL 出现在 AWR 的 Top SQL 列表中。你看到的通常是它的底层递归 SQL：MV$、MLOG$ 表扫描，或 INSERT/UPDATE/DELETE 语句。真正可追踪的是触发刷新的调度作业：
- DBMS_SCHEDULER 任务会以
PROGRAM_NAME或JOB_NAME形式出现在DBA_SCHEDULER_JOB_RUN_DETAILS，且其执行时间会被 AWR 快照捕获为“后台进程活动” - DBMS_JOB 任务则反映在
DBA_JOBS_RUNNING和DBA_JOBS中，但老版本 Oracle（如 10g）可能不完整计入 AWR；建议优先用DBA_SCHEDULER_JOB_LOG - 若刷新由 ON COMMIT 触发，则根本不会走后台作业——它绑定在每个事务提交上，此时必须看
Top 5 Timed Foreground Events是否出现异常的enq: TX - row lock contention或log file sync
从 AWR 报告里定位刷新作业的执行痕迹
生成 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 分）集中爆发，大概率对应定时刷新任务
用 SQL 直接查作业执行统计，比翻 AWR 更快
AWR 是宏观视图，细粒度执行记录得查数据字典：
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;
这段 SQL 能直接告诉你某刷新作业最近 7 天是否准时、间隔是否稳定。注意：status = 'SUCCEEDED' 才算一次有效刷新；'STOPPED' 或 'FAILED' 需结合 error# 字段查具体错误（常见如 ORA-12004、ORA-12052）。
容易被忽略的关键点：ON DEMAND 刷新 ≠ 有日志就一定执行
很多人以为建了 NEXT SYSDATE + 1/24 就万事大吉，结果发现物化视图三天没刷——因为：
- DBMS_SCHEDULER 默认启用
disabled状态，创建后必须显式执行DBMS_SCHEDULER.ENABLE('job_name') - 作业依赖的凭证（
CREDENTIAL_NAME）或程序（PROGRAM_NAME）若被删或失效，作业会静默跳过，DBA_SCHEDULER_JOB_LOG里只记STATUS = 'STOPPED'，不报错 - 如果物化视图定义里写了
REFRESH FAST ON DEMAND，但实际调用的是DBMS_MVIEW.REFRESH('mv', 'C')，参数写成'C'就强制全量刷，和定义无关
真正决定刷新行为的，永远是 DBMS_MVIEW.REFRESH 调用时传入的第二个参数，不是创建语句里的默认值。
