ORA-14099是数据越界错误，非结构问题；Oracle强制校验交换表中所有行的分区键值是否严格落在目标分区范围内，WITHOUT VALIDATION无效；定位需解析HIGH_VALUE后反向查询越界数据；修复仅限删除越界行或扩大分区边界。
ORA-14099 是分区键值越界，不是结构问题
ORA-14099 表示交换表中存在至少一行，其分区键值不落在目标分区的定义范围内——Oracle 在交换前强制校验，WITHOUT VALIDATION 也不能跳过这一步。它和 ORA-14097（列元数据不一致）、ORA-14098（索引不匹配）本质不同：这里不查字典、不比字段，只做数据扫描级检查。
- 错误信息里“all rows in table do not qualify for specified partition”是明确提示：数据本身越界了
- 比如目标分区是
VALUES LESS THAN (DATE '2026-07-01')，但交换表里有dt = DATE '2026-07-15'的行，就必然报错 -
WITHOUT VALIDATION对 ORA-14099 无效——这是 Oracle 内部硬编码逻辑，无法绕过
怎么快速定位越界数据？
别靠猜或全表扫描，用分区键范围反向过滤最直接：
- 先查目标分区的边界：
SELECT high_value FROM user_tab_partitions WHERE table_name = 'PART_TABLE' AND partition_name = 'P1' - 把
HIGH_VALUE解析成可比值（如TO_DATE('2026-07-01','YYYY-MM-DD')），再执行：SELECT COUNT(*) FROM staging_table WHERE part_key >= TO_DATE('2026-07-01','YYYY-MM-DD') - 如果结果 > 0，说明存在越界行；进一步查具体值：
SELECT part_key, COUNT(*) FROM staging_table GROUP BY part_key HAVING part_key >= ...
修复方式只有两种，没有第三种
ORA-14099 的修复路径非常窄，必须让数据严格落在分区定义内：
- 删掉越界数据：
DELETE FROM staging_table WHERE part_key >= :boundary，然后COMMIT - 或调整分区边界：重建分区表，把
VALUES LESS THAN改得更宽（例如从'2026-07-01'改为'2026-08-01'），再重试交换 - 注意：不能用
ALTER TABLE ... SPLIT PARTITION临时补救——交换操作要求目标分区已存在且定义固定
容易被忽略的关键点
ORA-14099 报错时，很多人下意识去改 DDL 或加 WITHOUT VALIDATION，但这两者都无济于事。真正卡住的是数据分布与分区定义之间的物理对齐关系——哪怕只多出一行越界记录，交换就失败。而且这个检查发生在交换语句解析阶段之后、执行之前，所以日志里不会显示“正在校验”，只会突然报错。
