oracle dbms_mview.refresh不支持直接按分区名刷新，但可通过pct机制实现逻辑分区级增量刷新；必须同时满足基表启用row movement、物化视图日志含分区键sequence及including new values、mv定义按相同列group by、创建时显式启用query rewrite和on query computation、调用时指定pct=>true，缺一即退化为全量或失败。
DBMS_MVIEW.REFRESH 本身不直接支持“按分区刷新”，但 Oracle 确实提供了 分区变化跟踪（PCT） 机制，可在满足严格前提下实现 逻辑上的分区级增量刷新——不是“只刷 P202603”，而是让 REFRESH FAST 自动跳过未变更的分区，仅处理被 DDL（如 EXCHANGE、SPLIT、ADD）或 DML 影响的分区。
这功能从 Oracle 10g 引入，12c/19c 持续强化，但极易因配置缺失而退化为全量刷新或报错。
PCT 刷新必须同时满足的硬性条件
漏掉任意一条，REFRESH FAST 就不会走 PCT 路径，而是回退到普通行级 FAST 或直接失败：
- 基表必须启用
ENABLE ROW MOVEMENT（否则EXCHANGE PARTITION会破坏日志一致性） - 物化视图日志必须显式包含分区键列，且带
SEQUENCE()和INCLUDING NEW VALUES，例如：CREATE MATERIALIZED VIEW LOG ON sales_tab WITH PRIMARY KEY, SEQUENCE(sale_date) INCLUDING NEW VALUES - 物化视图定义中必须按相同列
GROUP BY sale_date（不能是全表聚合，也不能用SELECT *） - 创建 MV 时必须显式指定
ENABLE QUERY REWRITE和ENABLE ON QUERY COMPUTATION PCT - 刷新调用必须传
PCT => TRUE，仅写'F'不生效：DBMS_MVIEW.REFRESH('mv_sales', 'F', PCT => TRUE)
为什么 REFRESH_FAST_AFTER_PCT 可能显示 'N' 或报 ORA-12052
常见原因不是语法错误，而是底层对象状态不匹配：
-
DBMS_MVIEW.EXPLAIN_MVIEW返回REFRESH_FAST_AFTER_PCT的possible = 'N'，通常意味着：物化视图日志里没把分区键放进SEQUENCE()，或 MV 定义中没按该列GROUP BY - 执行
REFRESH报ORA-12052，优先检查是否漏了ENABLE ON QUERY COMPUTATION子句——它和PCT是绑定的，缺一不可 - 即使建表时写了
PCT，若后续对基表执行了TRUNCATE TABLE，物化视图日志元数据会被破坏，PCT 自动禁用，需重建日志
PCT 刷新的实际效果与限制
它不是“手动指定分区名来刷”，而是 Oracle 内部根据 DBA_TAB_PARTITIONS 的 LAST_ANALYZED 和日志标记自动识别变更分区：
- 当只有 1 个分区被
INSERT或EXCHANGE，PCT 刷新耗时通常是普通 FAST 的 5%–20% -
ON COMMIT模式不支持 PCT，只能用于ON DEMAND+ 手动或 JOB 调度 - 物化视图含
JOIN、SYSDATE、ROWNUM等非确定性元素时，PCT 自动失效 - 它不解决 DML 频繁写入单一分区导致的日志膨胀问题——仍依赖物化视图日志，只是扫描范围缩小
真正容易被忽略的点是：PCT 不是开关，而是一组强耦合的状态。哪怕你建 MV 时全写对了，只要某天 DBA 清空了 MLOG$_xxx 表、或忘了在新增分区后重新收集统计信息，下次 REFRESH 就可能悄悄退化成全量。验证必须每次部署后跑一次 DBMS_MVIEW.EXPLAIN_MVIEW，不能只信 DDL 语句。
