INTERVAL分区表的物化视图REFRESH_FAST_PCT为N的根本原因是Oracle将自动创建的分区视为“动态存在”，无法在MV创建时静态绑定分区与行映射，因HIGH_VALUE边界运行时推导，不满足PCT要求的分区结构静态可枚举性。
为什么INTERVAL分区表的物化视图REFRESH_FAST_PCT为N
根本原因不是INTERVAL本身不支持PCT，而是Oracle在底层将自动创建的分区视为“动态存在”，无法在物化视图定义阶段静态绑定分区与行的映射关系。PCT（Partition Change Tracking）要求基表分区结构在MV创建时就可完全枚举，而INTERVAL分区的HIGH_VALUE边界是运行时推导的，导致DBMS_MVIEW.EXPLAIN_MVIEW返回capable_name = 'REFRESH_FAST_PCT'为N。
SELECT和GROUP BY中分区键必须原样暴露，且不能是INTERVAL列
即使你把log_time作为RANGE+INTERVAL分区键，在物化视图SQL里也必须满足：分区键列名完整出现在SELECT列表和GROUP BY子句中，不加函数、不加别名、不参与计算；但更关键的是——该列还必须是基表的**物理分区键列**，而非逻辑推导列。常见误操作：
-
SELECT TRUNC(log_time, 'MM'), COUNT(*) FROM sales_log GROUP BY TRUNC(log_time, 'MM')→ 函数包装直接禁用PCT -
SELECT log_time AS dt, COUNT(*) FROM sales_log GROUP BY dt→ 别名破坏字段可识别性 -
SELECT EXTRACT(YEAR FROM log_time), COUNT(*) FROM sales_log GROUP BY EXTRACT(YEAR FROM log_time)→ 表达式不可逆，无法对齐分区
正确写法只有一种：SELECT log_time, COUNT(*) FROM sales_log GROUP BY log_time，前提是log_time是单列RANGE分区键（非INTERVAL生成列），且基表未启用INTERVAL。
替代方案：用普通RANGE分区 + 手动ADD PARTITION代替INTERVAL
若业务强依赖PCT刷新，必须放弃INTERVAL自动建分区能力，改用显式RANGE分区，并配合调度任务定期ALTER TABLE ... ADD PARTITION。这样做的好处是：
- 分区结构静态可枚举，
DBMS_MVIEW.EXPLAIN_MVIEW能明确识别PCT能力 - 物化视图定义中
ENABLE QUERY REWRITE和PCT关键字可生效 - 交换分区（
EXCHANGE PARTITION）后，19c能精准触发PCT刷新，避免全量重刷
注意：手动分区需确保INCLUDING NEW VALUES已加入物化视图日志，否则FAST刷新本身就会退化。
验证PCT是否真生效，不能只看REFRESH FAST是否成功
很多DBA看到DBMS_MVIEW.REFRESH(..., 'F')没报错就以为PCT启用了，其实不然。必须查USER_MVIEWS视图确认：
SELECT mview_name, refresh_method, fast_refreshable, last_refresh_date FROM user_mviews WHERE mview_name = 'YOUR_MV';
其中fast_refreshable字段值必须为DIRLOAD_DML或DIRLOAD_LIMITEDDML，且含PCT字样（如DIRLOAD_DML,PCT）。如果只是DIRLOAD_DML，说明PCT未激活，刷新仍是全表扫描变更日志。
最易被忽略的一点：INTERVAL分区表上建的物化视图，哪怕SQL完全合规，PCT也永远不可用——这不是配置问题，是Oracle内核限制。想用PCT，就得接受放弃自动扩展，这是硬约束。
