Oracle不支持对间隔分区表启用PCT，这是内核硬限制；因间隔分区边界动态生成，PCT无法在编译期确定分区映射关系，故REFRESH_FAST_PCT恒为N，须改用预建范围分区并配合定期ADD PARTITION。
PCT不支持间隔分区表，这是Oracle内核硬限制
Oracle原生不支持对间隔分区（INTERVAL）表启用PCT。哪怕物化视图定义完全合规、基表已建日志、分区键显式暴露，只要底层基表是INTERVAL PARTITION，REFRESH_FAST_PCT在EXPLAIN_MVIEW输出中必然为N，且MSGTXT会明确提示“PCT not supported for interval partitioned tables”。这不是配置疏漏，而是12c至今未放开的限制。
为什么间隔分区被排除在PCT机制之外
间隔分区的边界由Oracle运行时动态计算并创建，没有预定义的、静态可枚举的分区集合。而PCT依赖于编译期就能确定的分区元数据映射关系——比如哪个分区号对应哪段VALUES LESS THAN边界。当新分区在INSERT时才自动产生，Oracle无法在刷新前可靠识别“哪些分区发生了变化”，也就无法构造增量变更范围。
- 执行
ALTER TABLE t SPLIT PARTITION或EXCHANGE PARTITION这类显式DDL时，PCT能捕获变更，因为操作目标明确 - 但
INSERT INTO t VALUES (..., DATE '2025-10-01')触发自动建分区，PCT无从感知该动作是否影响了物化视图的物化逻辑 -
USER_TAB_PARTITIONS里查到的分区可能比建MV时多出若干个，但PCT刷新路径根本不会扫描这些“后加”的分区
替代方案：用范围分区+手动维护，而非依赖间隔
若业务必须走PCT，唯一可行路径是放弃INTERVAL，改用标准RANGE PARTITION，并配合运维脚本定期预建未来分区：
- 建表时定义足够宽的范围，例如
PARTITION BY RANGE (sale_date) (PARTITION p_202401 VALUES LESS THAN (DATE '2024-02-01'), ...) - 用DBMS_SCHEDULER每月初自动执行
ALTER TABLE t ADD PARTITION预建下月分区 - 确保物化视图SQL中分区键列（如
sale_date）不加函数包装、不出现在子查询中、显式出现在SELECT和GROUP BY - 建MV时必须带
PCT和ENABLE QUERY REWRITE，再用EXPLAIN_MVIEW确认PCT和REFRESH_FAST_PCT两项均为Y
容易被忽略的关键点：PCT只响应DDL，不响应DML
即使你成功切换到范围分区并启用了PCT，也要记住：PCT刷新只在基表发生SPLIT/EXCHANGE/TRUNCATE/DROP分区时触发；日常INSERT/UPDATE/DELETE仍走物化视图日志路径。如果误以为“开了PCT就万事大吉”，却没维护好日志或没处理日志爆满，快速刷新一样会退化为完全刷新。
