Oracle 11g与19c物化视图快速刷新本质一致，但19c在分区表FAST刷新、WITH SEQUENCE强制性、INCLUDING NEW VALUES必要性、ON COMMIT限制提示、PCT优化及诊断能力上更稳健精准。
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 的诊断工具能更快告诉你为什么失效。
