Oracle 11g与19c物化视图增量刷新策略对比，具体差异是什么？

本文共计983个文字，预计阅读时间需要4分钟。

相关专题：

oracle 11g 和 19c 的物化视图快速刷新能力本质一致，但 19c 对分区表场景下的 fast 刷新支持更稳健、限制更少——关键差异不在“能不能”，而在“什么条件下能稳定用”。

物化视图日志的 WITH SEQUENCE 是否强制要求

11g 允许创建不含 WITH SEQUENCE 的物化视图日志，但一旦基表发生同一行多次更新（如 UPDATE … SET x=x+1 两次），FAST 刷新就可能丢失中间状态，结果错乱；19c 并未改变该行为，但官方文档和 DBMS_MVIEW.EXPLAIN_MVIEW 的诊断输出更明确地将缺失 WITH SEQUENCE 标记为“FAST 不安全”的前提。实践中，19c 环境下漏写它，DBA_MVIEWS.REFRESH_METHOD 可能仍是 'FAST'，但实际刷新时会静默退化为 COMPLETE，且不报错。

• 必须显式声明 WITH SEQUENCE，否则无法保证多更新场景下的增量一致性
• INCLUDING NEW VALUES 同样不可省略：否则 UPDATE 后的新值不会进日志，刷新后该列仍为旧值或 NULL
• 日志列列表必须覆盖物化视图 SELECT 中所有涉及列，包括 JOIN 条件列和 WHERE 中引用的列

ON COMMIT 刷新在分区表上的可用性差异

11g 对分区表启用 ON COMMIT 快速刷新存在隐式限制：若物化视图定义中含分区裁剪不友好的写法（如对分区键列使用函数：TRUNC(time_id)），即使日志合规，Oracle 也会拒绝 ON COMMIT 模式并报错 ORA-12052；19c 在相同场景下仍报错，但错误提示更具体，并增加了 DBMS_MVIEW.VALIDATE_MVIEW 的检查项，可提前暴露问题。

• ON COMMIT 要求基表和物化视图都满足“可确定性谓词”条件，分区键上避免函数包装
• 19c 的 VALIDATE_MVIEW 会返回详细原因字段（如 capable_name = 'REFRESH_FAST_AFTER_INSERT'），比 11g 的笼统报错更容易定位瓶颈
• 即便验证通过，ON COMMIT 在高并发 DML 下仍可能因锁竞争导致事务阻塞，这点两个版本无区别

分区变化跟踪（PCT）与快速刷新的协同表现

11g 引入了分区变化跟踪（Partition Change Tracking, PCT），用于加速分区表上物化视图的 FAST 刷新；19c 延续并优化了该机制，尤其在交换分区（EXCHANGE PARTITION）后，19c 能更准确识别哪些物化视图需要触发 PCT 刷新，而 11g 有时会误判为需全量重刷。

• PCT 刷新仅适用于物化视图定义中直接基于单一分区表、且 SELECT 不含聚合/JOIN 的简单场景
• 启用 PCT 需在建日志时加 INCLUDING NEW VALUES，并在 MV 定义中显式写 ENABLE QUERY REWRITE（虽非强制，但影响优化器是否选择 PCT 路径）
• 19c 中，DBA_MVIEW_ANALYSIS 新增了 PCT_REFRESHABLE 字段，可直接查出某 MV 是否真正支持 PCT，11g 需靠经验或反复测试推断

真正容易被忽略的是：无论 11g 还是 19c，只要物化视图定义里出现 UNION ALL、远程表（@dblink）、分析函数或非确定性函数（如 SYS_GUID()），FAST 刷新都会失效——这个限制没变，但 19c 的诊断工具能更快告诉你为什么失效。