DROP PARTITION 后全局索引立即变 UNUSABLE 是 Oracle 的强制一致性设计，非故障；因无法验证被删分区在全局索引叶节点中的键值有效性，故直接置为 UNUSABLE 以避免错误结果。
DROP PARTITION 后全局索引立即变 UNUSABLE 是设计行为，不是故障
Oracle 不会等你查完数据再决定索引是否可用——DROP PARTITION一执行完，所有关联的全局索引（index_type = 'NORMAL' 且非 LOCAL）状态就从 VALID 变成 UNUSABLE，不报错、不写 alert 日志、也不触发任何提示。这不是遗漏或 bug，是 Oracle 对 B-tree 一致性的强制保护：它无法局部验证被删分区在全局索引叶节点中残留的键值是否还指向有效数据块，所以选择“宁可停用，也不返回错误结果”。
本地索引 vs 全局索引：失效范围完全不同
本地索引（LOCAL）每个分区对应独立索引段，删分区 = 删掉对应索引段，其他分区索引照常工作；而全局索引是单一段、跨全表维护的 B-tree 结构，只要任意一个分区被删，整个索引结构就失去完整性保障，必须全量重建。哪怕删的是空分区，只要没加 UPDATE GLOBAL INDEXES，全局索引照样变 UNUSABLE。
为什么 UPDATE GLOBAL INDEXES 不是“修复命令”，而是 DDL 选项
UPDATE GLOBAL INDEXES 必须紧接在 ALTER TABLE ... DROP PARTITION 语句末尾、分号之前，不能单独执行，也不能事后补加。它只对本次 DDL 生效，对已发生的失效完全无效。常见误操作包括：
- 在已有
UNUSABLE索引状态下补执行ALTER TABLE ... DROP PARTITION UPDATE GLOBAL INDEXES—— Oracle 直接忽略该子句 - 把
UPDATE GLOBAL INDEXES写在注释后、换行后或拼错成UPDATE INDEXES—— 语法不识别，等同于没写 - 对
ADD PARTITION或RENAME PARTITION错误使用该子句 —— 这两个操作根本不支持该语法
确认失效不能只看 user_indexes.status
查 user_indexes 是第一步，但要注意：
-
status = 'UNUSABLE'就是明确信号，不用怀疑 -
funcidx_status = 'DISABLED'和分区无关，通常是函数索引依赖的对象失效，别混为一谈 - 如果是复合分区表（如
RANGE-LIST），还要查user_ind_partitions看局部索引分区状态，但全局索引没有分区视图，user_indexes足够
最简验证 SQL：SELECT index_name, status FROM user_indexes WHERE table_name = 'YOUR_TABLE' AND index_type = 'NORMAL';
重建前先显式 UNUSABLE 是关键安全动作
直接 ALTER INDEX ... REBUILD 风险高：若索引当前是 VALID，重建全程锁索引；若已是 UNUSABLE，某些 Oracle 版本会报 ORA-01408 拒绝执行。正确顺序是：
- 先快速置不可用：
ALTER INDEX idx_name UNUSABLE;—— 毫秒级，几乎不阻塞 DML - 再重建：
ALTER INDEX idx_name REBUILD TABLESPACE ts_name PARALLEL 4 LOGGING;—— 显式指定表空间、并行度和日志模式，避免默认NOLOGGING导致备库同步失败
真正容易被忽略的点是：重建完成前，唯一性全局索引（比如主键索引）会导致后续 INSERT 直接报 ORA-01502，而非静默跳过索引——这会让业务中断比预期更早、更突然。
