ora-14096/14097 报错源于交换表与分区列结构不一致，需脚本化比对column_name、顺序、data_type（含char/byte语义）、null属性、默认值、虚拟列、压缩及nls_comp；目标分区须truncate清空；staging表禁用主键/外键/check约束；交换前须验证分区键范围并收集统计信息；注意表空间一致性及全局索引失效问题。
ORA-14096/14097 报错时，先比对列定义再执行 EXCHANGE
报 ORA-14096 或 ORA-14097 不是语法写错了，而是交换双方列结构没对齐。肉眼检查容易漏掉细节，必须脚本化验证：
-
COLUMN_NAME、顺序、DATA_TYPE必须完全一致，VARCHAR2(50 CHAR)和VARCHAR2(50 BYTE)被视为不同类型 -
NULL属性必须相同：一方NOT NULL，另一方不能是可空 - 默认值、虚拟列、压缩属性、字符集语义（
NLS_COMP）也需一致 - 用
DBA_TAB_COLUMNS对比两边，别只看DESC输出
交换前必须清空目标分区，且 staging 表不能有非法约束
目标分区已有数据时，EXCHANGE PARTITION 会直接失败。不能靠 DELETE，要用 TRUNCATE PARTITION：
-
TRUNCATE PARTITION是 DDL，不走回滚段，无重做日志压力，秒级完成 - staging 表不能有主键、外键、
CHECK约束；NOT NULL可保留，但数据必须满足 - 如果 staging 表建了主键，哪怕加了
WITHOUT VALIDATION，Oracle 仍强制校验唯一性，可能触发ORA-14099 - 临时表建议用
CREATE TABLE ... AS SELECT构建，再手工补NOT NULL，避免继承原表约束
WITH VALIDATION 是默认行为，但数据合规性不能靠它兜底
WITH VALIDATION（默认）会扫描 staging 表所有行，确认每条记录都落在目标分区键范围内；WITHOUT VALIDATION 跳过这步，但风险极高：
-
ORA-14099出现说明数据越界，比如sale_date = DATE '2025-01-15'却要进LESS THAN (DATE '2025-01-01')的分区 - 加
WITHOUT VALIDATION不等于绕过问题——只是把错误延后到查询时暴露（返回空结果或报错） - 真正该做的是：交换前用
SELECT MIN(sale_date), MAX(sale_date) FROM staging_table显式验证范围 - 若 staging 表来自 ETL 加工，应在加载阶段就按分区键过滤，而非依赖交换时校验
交换后统计信息丢失，优化器会误判为空表
EXCHANGE PARTITION 不复制统计信息，目标分区的 NUM_ROWS 变为 0，可能导致后续 SQL 走全表扫描：
- 交换前，对 staging 表运行
DBMS_STATS.GATHER_TABLE_STATS - 交换后，立即对目标分区收集：
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA', tabname => 'TBL', partname => 'P_202507') - 不要用
COPY_TABLE_STATS，它只复制表级，不复制分区级统计 - 首次查询建议加 hint 如
/*+ INDEX(tbl tbl_idx) */强制走索引，并用DBMS_XPLAN.DISPLAY_CURSOR确认是否命中分区
EXCHANGE 语句里指定 TABLESPACE 子句，但老版本仍要求 staging 表和目标分区严格同表空间；而一旦目标表存在全局索引，交换后必然变为 UNUSABLE，必须重建——这事前没预案，上线就卡住。
