oracle 19c不支持分区级增量刷新，pct仅是在分区ddl变更后维持fast刷新能力的辅助机制，需同时满足row movement启用、日志含分区键列、mv按分区键group by、refresh显式指定pct=>true等强约束，缺一即失效。
oracle 19c 的分区更改跟踪（pct）不能单独“实现增量刷新”，它只是让 fast 刷新在分区表发生 ddl 变更（如 exchange、split）后仍能继续走增量路径，而不是直接退化为 complete。真要启用 pct 增量刷新，必须同时满足日志、建模、刷新调用三端的硬性约束，漏一不可。
为什么 PCT 不是开关，而是一组强依赖条件
PCT 不是给物化视图加个参数就生效的功能。它要求 Oracle 能把“哪个分区被改了”映射到“哪些物化视图行需要重算”，这依赖底层元数据和 SQL 结构的一致性：
- 源表必须启用
ROW MOVEMENT：否则EXCHANGE PARTITION会失败，间接破坏日志与分区状态的一致性 - 物化视图日志必须包含分区键列（如
sale_date），且显式写进SEQUENCE()列表中 - 物化视图定义的
SELECT必须按相同列GROUP BY（如GROUP BY sale_date），不能跨分区聚合（如全表SUM(amount)） -
REFRESH调用必须显式传PCT => TRUE，只写'F'不触发 PCT 逻辑
PCT 刷新 vs 普通 FAST 刷新的实际差异
普通 FAST 刷新扫描全部 MLOG$_sales 记录，再关联基表取最新值；PCT 刷新则先查 DBA_TAB_PARTITIONS，仅对标记为 “CHANGED” 的分区执行局部刷新，其余分区数据原样保留：
- 性能：当单次只修改 1 个分区（如每日新增分区），PCT 刷新耗时通常为普通 FAST 的 5%–20%
- 限制：PCT 不支持
ON COMMIT模式，只能用ON DEMAND+ 手动或 JOB 调度 - 兼容性：若物化视图含 JOIN 或非确定性函数（如
SYSDATE），PCT 自动失效，回退到常规 FAST
如何验证当前物化视图是否真正支持 PCT 增量刷新
不能只看建语句里有没有写 ENABLE QUERY REWRITE，必须运行诊断过程并检查输出：
BEGIN DBMS_MVIEW.EXPLAIN_MVIEW('MV_SALES_DAILY'); END; /
SELECT capability_name, possible, msgtxt FROM mv_capabilities_table WHERE mvname = 'MV_SALES_DAILY' AND capability_name = 'REFRESH_FAST_AFTER_PCT';
- 若
possible = 'Y'且msgtxt为空，说明 PCT 已就绪 - 若出现
"partition change tracking not supported"，说明建模未满足 PCT 条件（比如没按分区键GROUP BY，或日志缺分区键列） -
DBMS_MVIEW.VALIDATE_MVIEW会比 11g 更明确指出缺失哪一环，比如capable_name = 'REFRESH_FAST_AFTER_EXCHANGE'是否为 Y
PCT 最容易被忽略的两个实操细节
一是 PCT => TRUE 参数必须出现在 DBMS_MVIEW.REFRESH 调用中，且仅对已满足前提的物化视图有效；二是即使验证通过，PCT 刷新仍依赖分区元数据的准确性——如果手动 UPDATE 分区键值但未触发 ROW MOVEMENT，或用 INSERT /*+ APPEND */ 绕过日志写入，PCT 就会漏掉变更，导致结果不一致。这种错位不会报错，只会静默出错。
