alter table ... set interval 未生效是因为缺少非maxvalue的手工分区作为锚点；需确保分区键为单列date/timestamp/number、无maxvalue分区且非引用分区父表。
ALTER TABLE ... SET INTERVAL 为什么执行后没变化
直接执行 ALTER TABLE t SET INTERVAL NUMTOYMINTERVAL(1,'MONTH') 却发现分区没变、插入仍按旧步长建分区，大概率是表还没真正启用 interval 功能。Oracle 要求必须存在至少一个非 MAXVALUE 的手工分区作为“锚点”，否则 SET INTERVAL 只是语法通过，实际不生效。查一下 USER_TAB_PARTITIONS，如果 HIGH_VALUE 里还全是 MAXVALUE 或空值，说明 anchor 分区缺失。
修改前必须确认的三个硬性条件
Oracle 不允许对任意范围分区表执行 SET INTERVAL，以下任一不满足都会报 ORA-14759：
- 分区键必须是单列，且类型为
DATE、TIMESTAMP或NUMBER（不能是表达式或函数结果） - 当前不能存在
VALUES LESS THAN (MAXVALUE)分区——这是最常见翻车点 - 该表不能是任何引用分区（reference partitioning）的父表
已上线表如何安全切换 interval 步长
生产环境不能删表重建，推荐用在线重定义（DBMS_REDEFINITION）平滑过渡：
- 先建新表结构：含目标
INTERVAL和足够预留分区（比如覆盖未来 24 个月） - 调用
DBMS_REDEFINITION.START_REDEF_TABLE启动重定义 - 执行
SYNC_INTERIM_TABLE同步增量数据（减少最终锁表时间） - 最后
FINISH_REDEF_TABLE切换，原表名自动指向新结构
注意：切换瞬间会短暂锁表，且所有索引、约束、权限需手动迁移；别忘了在新表上收集统计信息，否则首次查询可能走错执行计划。
改完 interval 后最容易被忽略的副作用
步长变了，但历史分区不会自动合并或拆分——比如原来按天分，现在改成按月，已有的 30 个日分区依然各自独立，只是后续新数据按月落盘。这意味着：
-
USER_TAB_PARTITIONS行数不会减少，元数据膨胀照旧 - 分区裁剪仍有效，但跨月查询可能扫描更多分区（因边界不齐）
- 如果依赖
PARTITION_NAME做归档逻辑（如正则匹配P_202609），要同步更新脚本，避免漏掉SYS_P*自动命名的分区
真正的控制点从来不是“改 interval”，而是初始预留分区的粒度和覆盖时长——它决定了你多久才会再看到 SYS_P 开头的分区出现。
