Oracle 19c 不支持用 ALTER TABLE ... SET INTERVAL 修改间隔分区表的粒度，因元数据固化且初始分区与新间隔不兼容；唯一可行方案是重建表：导出DDL、修改INTERVAL表达式及p_initial边界、创建新表、迁移数据、验证分区、原子切换并同步依赖对象。
ALTER TABLE ... SET INTERVAL 不支持直接修改间隔粒度
Oracle 19c 不允许用 ALTER TABLE ... SET INTERVAL 把已有的 INTERVAL 分区表的粒度从「按月」改成「按年」或「按天」。这不是语法限制，而是元数据层面的硬性约束：间隔表达式（如 NUMTOYMINTERVAL(1,'MONTH')）一旦设定，就固化在数据字典中，无法 ALTER 修改。
常见错误现象是执行类似下面的语句后报错：
ALTER TABLE sales SET INTERVAL (NUMTOYMINTERVAL(2, 'MONTH'));
实际会触发 ORA-14758: Last partition in the range section cannot be dropped 或更底层的 ORA-14006: invalid partition name —— 因为 Oracle 试图重建间隔定义时，发现初始范围分区（p_initial）与新间隔不兼容，而它又不允许你先删掉这个分区。
唯一可行路径：重建间隔分区表
想改间隔粒度，本质是换一套分区逻辑，必须走「新建 + 迁移 + 切换」流程。这不是偷懒能绕开的，因为间隔元数据和历史分区段物理结构强绑定。
- 先用
DBMS_METADATA.GET_DDL导出原表 DDL，手动把INTERVAL表达式替换成目标粒度（例如从NUMTOYMINTERVAL(1,'MONTH')改成NUMTOYMINTERVAL(1,'YEAR')），并确保PARTITION p_initial VALUES LESS THAN (...)的边界值与新粒度对齐（比如按年就得设成TO_DATE('2023-01-01','YYYY-MM-DD')） - 创建新表时，**不要**直接
INSERT /*+ APPEND */ INTO new_table SELECT * FROM old_table—— 这会丢失分区键的自动路由能力；必须用CREATE TABLE ... AS SELECT或分批INSERT，让新表的间隔机制真正接管数据落盘位置 - 切换前检查新表的分区是否已按预期生成（查
USER_TAB_PARTITIONS），特别是验证第一个自动创建的区间分区（非p_initial）的时间范围是否符合新粒度 - 业务低峰期执行原子切换：
RENAME原表为备份名，再RENAME新表为目标名；注意索引、约束、权限、统计信息都要同步迁移
为什么不能用 DBMS_REDEFINITION 在线重定义？
很多人第一反应是用在线重定义（DBMS_REDEFINITION），但它对间隔分区表有明确限制：官方文档注明 CAN_REDEF_TABLE 会返回失败，错误提示为 ORA-14132: table has interval partitioning and cannot be redefined online。
根本原因在于间隔分区的「自动分区创建」行为依赖于实时的插入路径和内部元数据钩子，而重定义过程中的中间表无法继承这套动态机制——它只能是静态分区表。即使强行跳过检查，后续插入也会因缺失间隔逻辑导致数据全部落入 p_initial，彻底破坏分区设计。
容易被忽略的细节：初始分区边界必须手工对齐
重建时最常踩的坑，是只改了 INTERVAL 表达式，却忘了调整 PARTITION p_initial VALUES LESS THAN 的值。例如原表按月，p_initial 是 TO_DATE('2023-01-01','YYYY-MM-DD')；若改成按年，这个边界必须扩大到 TO_DATE('2023-01-01','YYYY-MM-DD') 依然合法，但更稳妥的是设成 TO_DATE('2023-01-01','YYYY-MM-DD')（即保持同一天），否则 Oracle 可能拒绝建表或导致首年数据全进 p_initial。
另外，所有依赖该表的物化视图、外部表、FGAC 策略、审计规则，都得在切换后重新验证——这些对象不会随表名 RENAME 自动更新引用。
