ora-14098本质是分区表与交换表的local索引定义不一致，非索引失效而是校验失败；需确保列名、顺序、类型、长度、空性完全匹配，或改用excluding indexes跳过校验。
Exchange Partition 本身不破坏索引，但校验失败或配置不匹配会导致操作中止或后续查询走全表扫描——问题不在“失效”，而在“不匹配”或“未显式维护”。
ORA-14098：本地索引定义不一致是主因
执行 EXCHANGE PARTITION 时报 ORA-14098，本质不是索引坏了，而是 Oracle 在校验阶段发现：非分区表（如临时表）上的每个非分区索引，没有在分区表上对应一个完全一致的 LOCAL 索引。
关键比对项包括：column_name、column_position、数据类型、长度、是否可为空——差一点就拒绝交换。
- 查两边索引列定义：用
SELECT index_name, column_name, column_position FROM user_ind_columns WHERE table_name IN ('PART_TABLE', 'TMP_TABLE') ORDER BY index_name, column_position - 若只是临时交换且不依赖索引性能，加
EXCLUDING INDEXES跳过校验（交换后手动重建即可） - 若必须带索引交换，且差异难对齐，可先对不匹配的索引执行
ALTER INDEX idx_name UNUSABLE，交换完成再REBUILD
全局索引没报错但查询变慢？检查是否残留 UNUSABLE 状态
即使 EXCHANGE 成功返回，全局索引也可能静默变成 UNUSABLE，尤其当没加 UPDATE GLOBAL INDEXES 或 DDL 中断时。此时 STATUS = 'VALID' 只表示逻辑标记正常，不代表物理可用。
- 查全局索引真实状态：用
SELECT index_name, status FROM user_indexes WHERE table_name = 'YOUR_TABLE' AND index_type = 'NORMAL' - 看到
status = 'UNUSABLE'就得处理；funcidx_status = 'DISABLED'可忽略（和函数索引相关，与交换无关） - 修复必须两步：先
ALTER INDEX idx_name UNUSABLE（毫秒级），再ALTER INDEX idx_name REBUILD PARALLEL 4 - 别信
UPDATE GLOBAL INDEXES能补救已发生的失效——它只对未来 DDL 生效
INCLUDING INDEXES 不等于自动兼容，细节决定成败
加了 INCLUDING INDEXES 并不保证成功，它只启用索引元数据交换，前提是两边索引结构真正等价。常见翻车点：
- 临时表有索引，但分区表上对应的是全局索引（
GLOBAL）而非本地（LOCAL）——Oracle 不认 - 索引列顺序不同，比如临时表是
(c, d)，分区表本地索引是(d, c)——直接报ORA-14098 - 字段类型隐式转换：临时表用
VARCHAR2(50)，分区表对应列是VARCHAR2(100)，虽兼容但索引定义不“完全一致” - 语法位置错误：
INCLUDING INDEXES必须紧接在EXCHANGE语句后、分号前，换行或被注释隔开即被忽略
最易被忽略的是：哪怕所有语法都对，只要交换过程中实例崩溃或会话被 kill，索引状态可能卡在中间态，STATUS 显示异常却无报错提示——必须靠查 user_indexes 主动确认，不能凭 DDL 是否“成功返回”做判断。
