为什么Oracle分区表在合并分区后索引会变为UNUSABLE？

根本原因是Oracle对MERGE PARTITIONS默认不维护全局索引，因数据块物理重写导致ROWID失效且B-tree无法局部验证，故直接置为UNUSABLE；本地索引因分区独立而不受影响。

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

oracle 对 merge partitions 操作默认不维护全局索引（global），因为合并过程会物理重写数据块位置，导致原有索引条目中指向旧分区的 rowid 失效；b-tree 结构无法局部验证这些条目是否仍有效，所以 oracle 选择立即将整个全局索引置为 unusable，而不是返回错误结果或部分可用状态。

本地索引（LOCAL）不受影响——每个分区索引段独立，MERGE 只删掉被合并的两个分区索引段、新建一个对应新区间的索引段，其余分区索引保持 USABLE。

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 会被阻塞或延迟，应用写入可能卡住——这不是理论风险，而是生产环境高频问题。所以别只盯着“能不能用”，得提前评估窗口期和业务容忍度。