DBMS_SCHEDULER是控制异步物化视图延迟的唯一可靠手段；START WITH/NEXT仅存元数据，不触发调度，故SYSDATE+1/1440无法实现1分钟自动刷新。
DBMS_SCHEDULER 是控制异步物化视图延迟的唯一可靠手段，START WITH/NEXT 仅存元数据，不触发任何调度。
为什么不能靠 NEXT SYSDATE + 1/1440 实现 1 分钟延迟
这是最常踩的坑：写完 CREATE MATERIALIZED VIEW ... REFRESH FAST ON DEMAND START WITH SYSDATE NEXT SYSDATE + 1/1440 后，物化视图永远不会自动刷新。Oracle 只把 NEXT 值存进 USER_MVIEWS.NEXT_DATE 字段，不创建作业、不启动后台线程、不检查时间是否到达。
-
NEXT字段可被DBMS_MVIEW.REFRESH调用时读取，但仅作参考；它不驱动任何行为 - 若误以为“写了 NEXT 就会准时刷”，结果是物化视图长期停留在初始快照状态
- 查询
DBA_SCHEDULER_JOBS会发现完全没对应作业，DBA_JOBS（旧机制）也为空
用 DBMS_SCHEDULER 精确控制延迟（秒级到分钟级）
真正可控的延迟必须由调度作业驱动，且需显式控制执行时机和失败重试逻辑：
- 延迟起点不是“源表变更时刻”，而是“作业触发时刻”——所以要让作业足够频繁，才能压缩端到端延迟
- 例如实现 ≤ 2 分钟延迟：设
repeat_interval => 'FREQ=MINUTELY; INTERVAL=2'，比设成每 1 分钟更稳（避免瞬时积压） -
start_date必须用SYSTIMESTAMP或带时区的TIMESTAMP，纯SYSDATE在跨时区环境可能漂移 - 加
max_runs => 999999和end_date => NULL防止作业意外终止
示例（2 分钟周期）：
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'j_mv_async_2min',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN DBMS_MVIEW.REFRESH(''mv_async_target'', ''F''); END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=MINUTELY; INTERVAL=2',
enabled => TRUE,
max_runs => 999999
);
END;
延迟不可控的三大隐藏瓶颈
即使作业配置正确，实际延迟仍可能远超预期，问题通常不出在调度本身：
-
job_queue_processes参数值太小（默认常为 0 或 10），导致作业排队；生产环境建议设为1000以上，并确认SELECT value FROM v$parameter WHERE name = 'job_queue_processes'返回非零值 - 物化视图日志（
MLOG$_xxx）膨胀或锁争用：当SELECT COUNT(*) FROM mlog$_sales返回几十万行，且DBA_JOBS.BROKEN = 'Y'或FAILURES > 0，说明刷新已卡住，延迟必然失控 -
DBMS_MVIEW.REFRESH执行耗时波动大：查USER_MVIEW_REFRESH_TIMES中最近几次的elapsed_seconds，若从 5 秒跳到 45 秒，说明底层 I/O 或 undo 压力已影响调度节奏
跨库场景下延迟必然升高，且无法规避
通过 @dblink 访问远程表时，FAST REFRESH 不可用，只能退化为 COMPLETE，这直接带来三重延迟叠加：
- 远程查询网络往返（尤其跨机房）
-
COMPLETE需全量重算 + 全量写入，耗时随基表增长非线性上升 - 远程 DB Link 密码过期、连接池空闲超时等故障会导致作业静默失败，
DBA_SCHEDULER_JOB_LOG中状态为FAILED但无明确报错
此时不要强求“低延迟”，应改用本地日志表+自定义同步：在源库解析 MLOG$_xxx，用 UTL_HTTP 或外部程序推送到目标库临时表，再 MERGE 到物化视图基表——这条路延迟可压到秒级，但需自行保障顺序与幂等。
