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。
