Oracle 19c无真正实时物化视图刷新，ON COMMIT模式实为同步阻塞式，拖慢业务提交且限制严苛；REFRESH FAST ON DEMAND配合DBMS_SCHEDULER是可控低延迟方案，但需规避日志失效、列缺失等导致静默降级为COMPLETE的陷阱。
Oracle 19c 没有真正的“Real-Time”物化视图刷新机制——所谓“实时”，实际是ON COMMIT 模式下最接近实时的同步行为，但它受限极多，且代价显著。你无法做到毫秒级、无延迟、跨库、带子查询或外连接的“实时”。
ON COMMIT 刷新为什么不是真正 Real-Time？
ON COMMIT 看似“事务一提交就刷”，但本质仍是同步阻塞式刷新：基表 COMMIT 会卡住，直到 MV 刷新完成才返回。这直接拖慢业务写入，常见现象是原本 0.02 秒的 COMMIT 变成 5~10 秒甚至超时。
- 必须满足 FAST REFRESH 所有前置条件（DB Link 不可用、主键/日志全齐、无子查询、无外连接、单表或等值 INNER JOIN）
- 不支持远程表（
ORA-12054：cannot create ON COMMIT materialized view with remote tables） - 若刷新失败（如日志缺失、权限不足、约束冲突），COMMIT 直接报错回滚，业务中断
- 高并发更新下，多个事务争抢 MV 刷新锁，极易引发死锁或长时间等待
REFRESH FAST ON DEMAND + 定时调度 ≠ Real-Time，但更可控
如果你需要的是“低延迟+可运维”的增量同步（比如秒级到分钟级），REFRESH FAST ON DEMAND 配合 DBMS_SCHEDULER 是唯一可行路径。它不卡业务，失败可重试，日志可查。
-
NEXT子句本身不触发刷新，必须依赖后台作业；确认job_queue_processes > 0（建议设为1000） - 不要用
DBMS_JOB，改用DBMS_SCHEDULER.CREATE_JOB：错误堆栈完整、支持邮件通知、失败自动重试 - 时间表达式必须返回
DATE类型，例如：NEXT SYSDATE + INTERVAL '30' SECOND（每30秒刷一次），不能写'SYSDATE + 30/86400' - 手动测试刷新前，先运行
EXEC DBMS_MVIEW.REFRESH('MV_NAME', 'F')，观察是否真走 FAST（耗时应稳定在毫秒级）；若耗时突增，说明已退化为 COMPLETE
为什么 EXPLAIN_MVIEW 显示 fastrefreshable=TRUE，刷新却很慢？
这是 Oracle 最隐蔽的坑：语法通过 ≠ 运行时 FAST。常见原因不是配置错，而是数据层“悄悄越界”。
- 源表主键被 DISABLE 或被 DROP 后重建，但物化视图日志未重建 → 日志失效，
REFRESH FAST静默降级为COMPLETE - 日志中漏了
INCLUDING NEW VALUES，导致无法捕获 UPDATE 前后值差异 → 只能全刷 - 查询中用了函数索引字段（如
UPPER(name)），但日志未包含该列 → FAST 不成立 - 执行
SELECT * FROM TABLE(DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME'))后，重点看MSGTXT列，凡含 “complex query”、“subquery”、“outer join” 字样，一律不可 FAST
真正低延迟的“实时”需求，在 Oracle 19c 中往往得绕开物化视图原生机制：比如用 LogMiner + 自定义应用消费变更，或接入 Tapdata / OGG 等 CDC 工具。物化视图的 FAST 刷新，本质是为“准实时报表”设计的，不是为“交易级一致性”服务的。别让它扛它扛不动的担子。
