Oracle分区表合并分区后索引变UNUSABLE原因

先提炼一个核心结论：Oracle 对 MERGE PARTITIONS 操作默认不会维护全局索引——因为合并过程中数据块物理位置被重写，原有索引条目指向旧分区的 ROWID 全部失效，而 B-tree 结构无法局部验证这些条目是否仍然有效，因此索性直接全部标记为 UNUSABLE。本地索引则无需担心：每个分区索引段相互独立，MERGE 只是删除两个旧分区的索引段，再新建一个对应新区间的索引段，其余分区索引照常可用。

ALTER TABLE MERGE PARTITIONS 后全局索引变为 UNUSABLE 的根本原因

Oracle 的 merge partitions 操作默认不维护全局索引（global），这一设计其实有其合理性。合并分区会物理重写数据块的位置，原有索引条目里的 ROWID 指向的地址已经失效。更关键的是，B-tree 索引无法只验证一部分节点是否有效——要么全对，要么全错。与其返回错误结果或处于半死不活的状态，Oracle 选择直接将整个全局索引置为 UNUSABLE，至少保证查询不会读到错误数据。

本地索引（LOCAL）之所以不受影响，是因为每个分区索引段相互独立。MERGE 时直接删除被合并的两个分区索引段，再新建一个对应新区间的索引段，其他分区的索引纹丝不动，自然不需要整体重建。

MERGE PARTITIONS 必须加 UPDATE GLOBAL INDEXES 才能避免失效

UPDATE GLOBAL INDEXES 可不是什么可选参数，它是防止索引静默失效的关键子句。加上之后，Oracle 会在 MERGE 执行过程中同步扫描并修正全局索引里所有指向被合并分区的条目——本质上等于隐式触发了全量重建。需要注意以下几个要点：

• 语法必须紧跟在主语句后、分号前：ALTER TABLE t MERGE PARTITIONS p1, p2 INTO PARTITION p_new UPDATE GLOBAL INDEXES;
• ONLINE 与 UPDATE GLOBAL INDEXES 不能同时使用（MERGE PARTITIONS 本身就不支持 ONLINE）
• 如果表上有多个全局索引，这个子句会一并维护；只要任一索引维护失败（比如空间不足、唯一键冲突），整个 DDL 就会回滚
• 已经处于 UNUSABLE 状态的索引，再补这个子句也无效——DDL 会直接报错或忽略，必须先执行 ALTER INDEX idx_name REBUILD

为什么加了 UPDATE GLOBAL INDEXES 还报 ORA-01502？

生产环境里经常遇到这种情况：语法没写错，执行也成功了，结果一查索引还是 UNUSABLE。排查时优先盯住这三件事：

• 执行前先查 SELECT index_name, status FROM user_indexes WHERE table_name = 'YOUR_TABLE'——如果已经有 UNUSABLE 的索引，DDL 不会自动修复，必须先重建
• DDL 执行中途被打断（比如 kill session 或实例崩溃），Oracle 只回滚表结构变更，索引残留中间态，状态不会自动回退
• 执行账号对索引缺少 ALTER 权限：维护会跳过且不报错，只在日志里留警告，极易忽略

MERGE 分区时全局索引重建的实际开销

UPDATE GLOBAL INDEXES 的实际工作就是全索引扫描 + 重建，耗时与索引大小直接相关。实测下来，相比不加这个子句，单次 MERGE 可能慢 3 到 10 倍，尤其当索引键值分布比较稀疏、DML 并发高的时候，锁持有时间会显著拉长。

还有一个更隐蔽的风险：联机维护期间，全局索引上的 INSERT/UPDATE 会被阻塞或延迟，应用写入可能卡住——这不是理论推演，而是生产环境的高频事故。所以别光想着“能不能用”，得提前评估好窗口期和业务容忍度。