ORA-14099 表示待交换普通表中存在行数据不满足目标分区键值范围（如sale_date='2025-01-15'却要交换至LESS THAN('2025-01-01')的分区），必须确保所有行严格符合范围条件；加WITHOUT VALIDATION仅跳过校验但不解决数据合规性，且无法绕过主键/唯一约束强制的WITH VALIDATION。
exchange partition 不是“把数据搬进去”，而是把段指针一换——只要结构对得上、表空间在一块、约束不打架，千万行也能秒级完成。
为什么 exchange partition 会报 ORA-14099 或直接失败
ORA-14099 表示临时表里的数据不满足目标分区的键值范围，比如你拿一个含 sale_date = DATE '2025-01-15' 的表去交换 P_2024Q4（范围是 LESS THAN (DATE '2025-01-01')），就会触发校验失败。即使加了 WITHOUT VALIDATION，也只是跳过检查，但后续查这个分区时可能返回空或报错。
- 必须确保临时表中所有行都落在该分区定义的键值范围内；
- 如果临时表有主键或唯一约束，Oracle 会强制执行
WITH VALIDATION，不管是否显式写了WITHOUT； - 列顺序、数据类型、
NOT NULL属性、默认值、压缩属性、字符集语义必须完全一致，差一个VARCHAR2(50 CHAR)vsVARCHAR2(50 BYTE)就会失败； - 临时表和目标分区必须在同一个表空间（Oracle 12c+ 可配
TABLESPACE子句绕过，但老版本如 11.2.0.4 仍严格要求）。
INCLUDING INDEXES 是不是总该加
加 INCLUDING INDEXES 只影响本地索引（LOCAL），它会把临时表上同名、同列、同属性的本地索引直接绑定到分区上；但全局索引（GLOBAL）不会自动更新，会变成 UNUSABLE 状态，必须重建或用 UPDATE GLOBAL INDEXES（后者代价高，不推荐用于大表）。
- 临时表必须已建好对应本地索引，且名字、列顺序、排序方向、
COMPRESS设置完全一致； - 如果临时表没建索引，加
INCLUDING INDEXES会报 ORA-14643； - 若想省事，先不加该子句，交换完再对分区单独建本地索引（
CREATE INDEX ... LOCAL ON TABLE(PARTITION)）更可控； - 全局索引别指望
INCLUDING INDEXES帮你修好——它根本不管。
如何避免交换后查询变慢或统计信息丢失
EXCHANGE 操作本身不复制数据，也不继承统计信息：原分区的 NUM_ROWS、AVG_ROW_LEN 等全部清零，优化器会误判为空表，导致走错执行计划。
- 交换前，务必对临时表收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS； - 交换后，立即对目标分区收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS(ownname => ..., tabname => ..., partname => 'P_202504')； - 不要依赖
DBMS_STATS.COPY_TABLE_STATS——它只复制表级统计，不复制分区级； - 如果用了
WITHOUT VALIDATION，记得手动验证分区键分布，比如：SELECT MIN(sale_date), MAX(sale_date) FROM sales_202504； - 交换后首次查询建议加 hint 强制走分区剪枝，确认是否真的命中目标分区。
真正“零拷贝”的边界在哪
所谓零拷贝，仅指不移动数据块（extents），但仍有元数据变更 I/O 和 buffer cache 刷脏开销。一旦违反前提条件，Oracle 会悄悄退化为物理迁移——比如字段长度不一致时，它会新建临时段、逐行转换再交换，此时耗时从秒级变成小时级。
- 最隐蔽的陷阱是隐式类型转换：临时表用
NUMBER，分区键是NUMBER(10)，看似兼容，但 Oracle 内部可能拒绝交换； -
WITH VALIDATION在大数据量下会全扫临时表，哪怕只是做键值范围检查，也可能卡住； - 如果目标分区已有数据，交换会失败（ORA-14098），必须先清空或用
TRUNCATE PARTITION； - 别在业务高峰期执行——虽然快，但持有 DDL 锁期间，所有对该分区的 DML 都会被阻塞。
