ORA-14074 错误本质是分区边界冲突，即新增Range分区的VALUES LESS THAN值必须严格大于现有最后一分区上限；若存在PMAX则需先SPLIT而非DROP，并注意分区键类型、HIGH_VALUE格式及锁影响。
ORA-14074 错误本质是分区边界冲突
这个错误不是语法错，而是 Oracle 对 Range 分区结构的强制校验：你试图添加的新分区 VALUES LESS THAN 边界必须严格大于最后一个现有分区的上限值。如果表里存在 PMAX（即 VALUES LESS THAN (MAXVALUE)），那它在逻辑上“封顶”了整个范围分区段——后续任何 ADD PARTITION 都会因无法定义更高边界而失败。
不能直接 DROP PMAX，但可以 SPLIT 它
很多人第一反应是删掉 PMAX，但执行 DROP PARTITION PMAX 会触发 ORA-14074 或更早的 ORA-14758。正确做法是用 SPLIT PARTITION 把 PMAX 拆开，既保留历史数据，又腾出新边界：
-
SPLIT PARTITION PMAX AT (202001) INTO (PARTITION P202001, PARTITION PMAX)—— 注意AT值必须是合法、可比较的字面量（如数字、日期字符串），且要与分区键类型一致 - 每执行一次
SPLIT，就多出一个新分区，PMAX自动收缩为剩余未分配部分 - 若需连续加多个分区，重复执行
SPLIT即可，无需先ADD再SPLIT - 务必加上
UPDATE GLOBAL INDEXES，否则全局索引会失效
注意分区键类型和 high_value 格式
查 USER_TAB_PARTITIONS.HIGH_VALUE 时看到的不是原始值，而是 Oracle 内部表达式（比如 TO_DATE(' 2012-01-01 00:00:00', ...)）。这意味着：
- 如果你的分区键是
DATE类型，AT后面必须用DATE字面量或能隐式转换的字符串（如DATE '2020-01-01'），不能写202001 - 如果是
NUMBER类型（如按月编号202001），AT值就得是纯数字，不能加引号 - 执行前用
SELECT HIGH_VALUE FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'YOUR_TABLE' ORDER BY PARTITION_POSITION DESC确认最后一行的真实边界
在线业务下慎用 SPLIT 的锁行为
SPLIT PARTITION 是 DDL 操作，默认需要对整个分区加排他锁。虽然比全表重建轻量，但在高并发写入场景下仍可能阻塞 DML：
- 拆分大分区（尤其含大量数据的
PMAX）耗时较长，期间该分区上的 INSERT/UPDATE/DELETE 会被挂起 - 建议在低峰期执行；若必须白天操作，可配合
ONLINE关键字（Oracle 12c+ 支持，但仅限某些版本和配置） - 拆分后记得检查索引状态：
SELECT INDEX_NAME, STATUS FROM USER_INDEXES WHERE TABLE_NAME = 'YOUR_TABLE'，失效的全局索引需手动REBUILD
真正麻烦的不是语法怎么写，而是得先看清 HIGH_VALUE 里藏的是日期还是数字、有没有 NLS 影响隐式转换——这些细节漏掉，SPLIT 就会报莫名其妙的 ORA-14000 系列错误。
