仅靠 start with 和 next 无法实现自动刷新——它们只存元数据，不启动后台任务；oracle 19c 必须用 dbms_scheduler.create_job 创建并启用真实作业才能定时刷新。
仅靠 START WITH 和 NEXT 无法实现自动刷新 —— 它们只存元数据，不启动任何后台任务。
为什么 CREATE MATERIALIZED VIEW ... REFRESH ON DEMAND START WITH SYSDATE NEXT SYSDATE+1 不工作
这是最常踩的坑：语句能成功执行，物化视图也能建出来，但第二天数据完全没变。因为 START WITH/NEXT 只是把调度计划写进数据字典（如 DBA_MVIEWS.REFRESH_TIME），Oracle 19c 不再用旧版 DBMS_JOB 自动拉起刷新。它不会创建、启用或运行任何作业。
- 查状态：
SELECT refresh_mode, refresh_method, last_refresh_date FROM dba_mviews WHERE mview_name = 'YOUR_MV'，你会发现last_refresh_date始终为空或停留在创建时刻 - 错误认知：“写了
NEXT就等于加了定时器” → 实际上等于什么都没调度 - 兼容性陷阱：该语法在 12c 之后已纯属“占位符”，官方文档明确标注为 legacy behavior，不保证执行
必须用 DBMS_SCHEDULER.CREATE_JOB 创建真实可运行作业
这是 Oracle 19c 中唯一受支持、可生产落地的定时刷新路径。关键不是“怎么写物化视图”，而是“怎么让作业真正跑起来”。
- 作业必须显式
enabled => TRUE，否则只是躺在数据字典里 -
job_action必须是合法 PL/SQL 块，且字符串内单引号要双写：'BEGIN DBMS_MVIEW.REFRESH(''mv_sales_daily'', ''F''); END;' -
repeat_interval推荐用命名表达式：'FREQ=DAILY; BYHOUR=2; BYMINUTE=0'，比SYSDATE+1更可靠（后者在跨天时可能因会话时区偏移出错） - 首次触发时间
start_date建议用TRUNC(SYSDATE)+2/24（即今天凌晨 2 点），避免用SYSDATE导致作业立刻触发、干扰业务高峰
刷新失败的三个高频原因和验证点
即使作业创建成功，DBA_SCHEDULER_JOB_LOG 里仍可能出现 STATUS = 'FAILED'。别急着重试，先看这三项：
-
DBMS_MVIEW.REFRESH调用权限缺失：执行作业的用户必须有EXECUTE权限 onDBMS_MVIEW，且对基表有SELECT（不是SELECT ANY TABLE） - 快速刷新不可用：
SELECT fast_refreshable FROM dba_mviews WHERE mview_name = 'YOUR_MV'返回'NO'？说明日志缺失字段、查询含SYSDATE或连接条件无索引 - 物化视图日志膨胀阻塞：大更新后
MLOG$_xxx表未清理，DBMS_MVIEW.REFRESH扫描日志超时；可手动执行DBMS_MVIEW.PURGE_LOG('your_table', 1)清理 1 天前日志
真正生效的自动刷新，依赖三者严丝合缝：物化视图定义为 ON DEMAND + 合规日志存在 + DBMS_SCHEDULER 作业启用且权限到位。少一个，就卡在“看起来配好了，实际不动”。
