ORA-14074错误本质是分区边界冲突，需用SPLIT PARTITION替代ADD操作，将含MAXVALUE的兜底分区按AT值精准拆分为新区间和保留MAXVALUE的分区，并注意锁、索引及长期改用INTERVAL分区。
ORA-14074 错误本质是分区边界冲突，不是语法写错
当你执行 ALTER TABLE ... ADD PARTITION 报 ORA-14074: partition bound must collate higher than that of the last partition，说明表里已存在一个 VALUES LESS THAN (MAXVALUE) 分区（比如叫 p_max），而你试图加的分区边界值 ≤ 它的下界 —— Oracle 不允许在 MAXVALUE 后“追加”，只允许“拆分”。这不是权限或拼写问题，是分区结构本身的限制。
必须用 SPLIT 替代 ADD，且 AT 值要精准对齐业务需求
SPLIT PARTITION 是唯一合规解法，核心是把兜底分区一分为二：前半段承接新边界数据，后半段仍是 MAXVALUE 兜底。操作要点：
- 确认目标分区名：查
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'YOUR_TABLE'，找到high_value含MAXVALUE的那个分区（如p_max） -
AT值必须严格等于你希望新分区的上限：比如要为 2025 年 1 月数据建分区，AT就得是TO_DATE('2025-01-01', 'YYYY-MM-DD')，不是'2025-01-02'也不是DATE '2025-01-01'（注意函数和字面量兼容性） - 拆分语句示例：
ALTER TABLE sales SPLIT PARTITION p_max AT (TO_DATE('2025-01-01','YYYY-MM-DD')) INTO (PARTITION p_202501, PARTITION p_max) - 拆分后原
p_max变成新区间[2025-01-01, MAXVALUE)，新数据自动落入其中；p_202501实际覆盖[旧下界, 2025-01-01)
执行 SPLIT 前必须评估锁与性能影响
SPLIT PARTITION 是 DDL 操作，会持有一个 **EXCLUSIVE 表级锁**，阻塞所有 INSERT/UPDATE/DELETE，甚至 SELECT FOR UPDATE。这点极易被忽略：
- 务必安排在业务低峰期，提前通知应用方暂停写入
- 如果表有全局索引（
GLOBAL INDEX），默认会失效，需加UPDATE GLOBAL INDEXES子句，但会显著延长执行时间 - 拆分不移动现有数据，只修改数据字典，所以本身很快；慢主要来自索引维护和锁等待
- 验证是否成功：查
user_tab_partitions确认新分区已存在，且high_value正确更新
长期方案：改用 INTERVAL 分区避免反复手动干预
如果分区按固定周期递增（如每月、每日），硬编码每个分区终将失控。INTERVAL 分区能自动创建新分区，但需满足：
- 分区键必须是单个 NUMBER 或 DATE 列（不能是表达式）
- 初始必须定义至少一个范围分区（如
P1 VALUES LESS THAN (DATE '2024-01-01')），再用SET INTERVAL开启自动 - 切换命令：
ALTER TABLE sales SET INTERVAL (NUMTOYMINTERVAL(1, 'MONTH'))（按月）或NUMTODSINTERVAL(1, 'DAY')（按天） - 切换后，首次插入超出当前最大分区边界的记录，Oracle 自动创建对应分区，无需人工介入
真正麻烦的不是某次 SPLIT 操作，而是每次都要查分区名、算 AT 值、协调停机窗口 —— 这些细节堆在一起，才是 DBA 夜不能寐的原因。
