ORA-14400 根因是 RANGE 分区未设 MAXVALUE，导致插入值超出最后 high_value 或为 NULL 时失败；需查 user_tab_partitions 确认末分区 high_value 是否为具体值而非 MAXVALUE，补救用 SPLIT 或 EXCHANGE，根治应建表时包含 MAXVALUE 或改用 INTERVAL 分区。
ora-14400 不是数据或权限问题，而是分区边界卡死——没设 maxvalue，插入值一超最后那个 high_value 就直接失败。
查确认：最后一行 high_value 是不是具体值而不是 MAXVALUE
执行这条语句，重点看结果里最后一行的 high_value：
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'YOUR_TABLE_NAME' ORDER BY partition_position;
如果返回类似 TO_DATE('2025-01-01','YYYY-MM-DD') 或 1000 这种带具体值的字符串，且没有一行显示 MAXVALUE，那就坐实了问题。注意：high_value 是 RAW 类型，实际内容要靠 DBMS_METADATA 或 XMLTYPE 解析才看得清，但对多数业务表（按日期/数字 range 分区），肉眼比对末尾是否含 MAXVALUE 已足够判断。
补救操作：不能直接 ADD PARTITION，得用 SPLIT 或 EXCHANGE
RANGE 分区要求边界严格递增，MAXVALUE 只能是最后一个分区。所以你不能在末尾直接加一个新分区，Oracle 会报 ORA-14074（partition bound must be higher than that of the last partition）。
-
SPLIT PARTITION：选当前最高分区（比如P_202512），把它切成两半，上半段让给MAXVALUE。例如：ALTER TABLE your_table SPLIT PARTITION P_202512 AT (TO_DATE('2026-01-01','YYYY-MM-DD')) INTO (PARTITION P_202512, PARTITION P_MAXVALUE);注意：这个操作会锁住该分区，期间无法写入该分区数据。 -
EXCHANGE PARTITION：更稳妥但步骤多。先建结构一致的临时表，把原分区数据导出再交换进来，最后重建带MAXVALUE的新分区布局。前提是临时表的列类型、NOT NULL 约束、索引定义必须完全匹配，差一点就报ORA-14097。
根治方案：建表时就带 MAXVALUE，或改用 INTERVAL 分区
手建 RANGE 分区表时漏掉 MAXVALUE 是高频失误。正确写法示例：
CREATE TABLE t_log (id NUMBER, log_time DATE)
PARTITION BY RANGE (log_time) (
PARTITION p_old VALUES LESS THAN (TO_DATE('2024-01-01','YYYY-MM-DD')),
PARTITION p_2024 VALUES LESS THAN (TO_DATE('2025-01-01','YYYY-MM-DD')),
PARTITION p_max VALUES LESS THAN (MAXVALUE)
);
更省心的是直接用 INTERVAL 分区（Oracle 11gR2 起支持）：
CREATE TABLE t_log_auto (id NUMBER, log_time DATE)
PARTITION BY RANGE (log_time) INTERVAL (NUMTODSINTERVAL(1,'DAY'))
(PARTITION p_first VALUES LESS THAN (TO_DATE('2024-01-01','YYYY-MM-DD')));
它自动在需要时创建新分区，且隐式包含 MAXVALUE 逻辑，彻底避开人工维护边界的风险。
NULL 值也会触发 ORA-14400？是的，没 MAXVALUE 时 NULL 被视为“无穷大”
这点容易被忽略：如果分区键字段允许为 NULL，而表又没定义 MAXVALUE 分区，插入 NULL 会直接报 ORA-14400。Oracle 把 NULL 当作比任何非空值都大的特殊值，但它必须落在某个分区范围内——只有 MAXVALUE 才能兜住它。所以即使业务中 NULL 很少，只要存在这种可能，MAXVALUE 就不是可选项，而是必需项。
