为何Oracle 11g局部索引在分区删除后会变成不可用状态

Oracle 11g局部索引DROP PARTITION后状态仍显示USABLE但实际不可用，因对应索引分区被物理删除而未更新状态，查询时触发ORA-01502；11g不支持UPDATE INDEXES语法，须手动重建分区索引。

局部索引在 DROP PARTITION 后状态仍显示 USABLE，但实际不可用

oracle 11g 的局部索引（local）在执行 alter table ... drop partition 后，dba_indexes.status 或 user_indexes.status 通常仍显示为 usable，但这只是“表层状态”。真正的问题藏在分区级：被删分区对应的索引分区段已被物理删除，而 oracle 并不自动更新索引整体状态，也不重建剩余分区的索引结构。查询一旦落到原分区键范围（哪怕数据已不存在），就会触发 ora-01502 —— 因为执行计划试图访问一个已不存在的索引分区。

11g 不支持 UPDATE INDEXES 子句修复局部索引

很多人误以为加个 UPDATE INDEXES 就能自动兜底，但在 Oracle 11g 中：

• ALTER TABLE ... DROP PARTITION UPDATE INDEXES 会直接报错 ORA-00922: missing or invalid option
• 该语法从 12.2 才开始支持，且仅对 LOCAL 索引生效（对 GLOBAL 无效）
• 11g 下即使手动写上，DDL 也会被拒绝，不会静默忽略

这意味着你必须主动干预，不能依赖语法糖。

TRUNCATE PARTITION 对局部索引的影响更隐蔽

TRUNCATE PARTITION 不删结构，只清数据，但它会明确把对应索引分区的状态设为 UNUSABLE（可查 dba_ind_partitions.status）。这个变化不会阻塞 DML，但后续任何涉及该分区键的 SELECT 或唯一性约束检查都会失败。关键点：

• UPDATE INDEXES 对 TRUNCATE 完全不生效 —— 它只响应 DROP 和 SPLIT
• 必须显式执行 ALTER INDEX idx_name REBUILD PARTITION p_name
• 重建期间仅该分区索引不可用，其他分区照常工作，这是局部索引的优势，也是你得逐一分区确认的原因

为什么不能只查 user_indexes.status 就判断可用性

在 11g 中，仅查 user_indexes.status 是危险的：

• 它只反映索引整体元数据状态，不体现各分区实际存在性
• 局部索引可能整体 USABLE，但多个 dba_ind_partitions.status 是 UNUSABLE 或空（表示分区段已删）
• 正确做法是联合查询：
  SELECT index_name, partition_name, status FROM user_ind_partitions WHERE index_name = 'YOUR_IDX';
• 若某分区行缺失（不是 UNUSABLE 而是根本查不到），说明该索引分区已被物理删除，等同于失效

最易被忽略的是：问题往往不出现在刚删的分区，而是出现在后续插入/查询时才暴露——因为 Oracle 直到执行计划真正需要那个索引分区时，才抛出 ORA-01502。