- ORA-14097 这个错，说白了就是 Oracle 把交换表和分区表丢进
sys.col$ 字典里，一个字段一个字段地怼着字节去比对。只要 column_id、data_type、data_length、nullable、默认值、隐藏列、未使用列里头，哪怕有一个地方不一样，它就立刻翻脸——而且还不告诉你到底哪儿没对上。很多人在折腾分区交换时都撞上过这条，Oracle 不告诉你具体哪儿不对，就直接来一句“类型或尺寸不匹配”。我们先从根源上看看，问题到底出在哪儿。
列顺序错一位就失败：Oracle 只认 column_id，不认列名
很多人喜欢用 CREATE TABLE AS SELECT * 来建交换表，觉得省事。但哪怕字段名和类型一个不差，只要源表定义是 (id, name, created_at)，而你中间表写的是 SELECT name, id, created_at FROM ...，那 column_id 早就错位了，你一交换，ORA-14097 马上就跳出来。要查真实顺序，跑这条语句就知道了：SELECT column_name, column_id FROM user_tab_columns WHERE table_name IN ('PART_TABLE', 'STAGING_TABLE') ORDER BY table_name, column_id
修复方式不是去改 SQL 里的列顺序，而是用 DBMS_METADATA.GET_DDL('TABLE', 'PART_TABLE') 拿到原始 DDL，完整执行一遍建表语句。有时候你手写建表，漏掉一个逗号或者换行错位，也可能导致 column_id 偏移，这种细节特别容易踩坑。
VARCHAR2(100) 和 VARCHAR2(100 CHAR) 是两种类型
Oracle 内部记录的 data_type 和 data_length 不一样，哪怕你肉眼看不出区别。比如 VARCHAR2(100 CHAR) 在 UTF8 编码下存储时，data_length 可能是 150 字节，而不是 50 字节。用 CTAS 建表时不继承字符语义，VARCHAR2(100) 的 CTAS 结果默认是 VARCHAR2(100 BYTE)，但源表是 VARCHAR2(100 CHAR)，两边一比对，直接失败。类似这样的情况还有 NUMBER vs NUMBER(10,0)、DATE vs TIMESTAMP(6)、CHAR(10) vs VARCHAR2(10)，都得用这套语句去查底层定义：SELECT column_name, data_type, data_length, data_precision, nullable FROM user_tab_columns WHERE table_name IN ('PART_TABLE', 'STAGING_TABLE') ORDER BY table_name, column_id
NOT NULL、隐藏列、未使用列这些“看不见”的东西也必须一致
这些字段不会出现在 DESC 或者简单的 DDL 里，但 Oracle 交换时会读 sys.col$，任何差异都直接拒绝。查隐藏列可以跑这条语句：SELECT column_name, hidden_column, virtual_column FROM user_tab_cols WHERE table_name IN ('PART_TABLE', 'STAGING_TABLE') AND (hidden_column = 'YES' OR virtual_column = 'YES')。查未使用列：SELECT column_name FROM user_tab_cols WHERE table_name = 'XXX' AND unused_col_count > 0，两边都要清理，用 ALTER TABLE xxx DROP UNUSED COLUMNS 去掉。
CTAS 不继承 NOT NULL 约束，哪怕源表该列是主键的一部分，交换表对应列的 nullable 仍然是 'Y'，必须手动补上：ALTER TABLE staging_table MODIFY (col_name NOT NULL)。默认值也是一样的道理，CTAS 会丢掉 DEFAULT，需要显式加回来，否则 sys.col$.default$ 字段内容不同也会导致失败。
带索引交换（INCLUDING INDEXES）会额外校验本地索引结构
不只是表结构要一致，INCLUDING INDEXES 还要求分区表的 LOCAL 索引与交换表的普通索引在列顺序、column_position、data_type、排序方向（ASC/DESC）、COMPRESS 设置上完全镜像。查索引列序可以用这个：SELECT column_name, column_position FROM user_ind_columns WHERE index_name = 'IDX_LOCAL' AND table_name = 'PART_TAB' ORDER BY column_position。再查交换表索引：SELECT column_name, column_position FROM user_ind_columns WHERE index_name = 'IDX_STG' ORDER BY column_position。二者输出必须逐行完全相同，稍有偏差就会报 ORA-14098。最省事的做法是改用 EXCLUDING INDEXES，交换完再重建 LOCAL 索引：CREATE INDEX idx_local ON target_table(partition_col) LOCAL。
真正麻烦的不是某一项没对齐，而是 Oracle 不提示具体哪项不一致，只能靠字典视图逐项比对。生产环境大表重建不可行时，往往得靠 user_tab_columns、user_tab_cols、user_ind_columns 三张视图交叉核对，漏掉任何一个字段属性，都会卡在 ORA-14097。我觉得最头疼的就是这种“只告诉你错，不告诉你哪儿错”的情况，所以提前做好准备，把所有可能的点都排查一遍，才是唯一可靠的解法。
