如何查询分区索引状态_DBA_IND_PARTITIONS排查UNUSABLE失效的分区索引-Oracle-PHP中文网

必须查DBA_IND_PARTITIONS确认分区索引状态，STATUS为UNUSABLE才真正失效，仅靠USER_INDEXES的VALID状态会误判；重建需指定分区名并收集统计信息验证。

分区索引某几个分区失效，但整体 user_indexes 里状态还是 valid，容易误判。必须进分区粒度查——dba_ind_partitions 才是真相。

关键字段就两个：STATUS（值为 UNUSABLE 才真挂了）、PARTITION_NAME（定位具体哪个分区）。

SELECT index_name, partition_name, status FROM DBA_IND_PARTITIONS WHERE index_name = 'YOUR_IDX' AND status = 'UNUSABLE';
注意：DBA_IND_PARTITIONS 是数据库级视图，普通用户可能没权限，换成 USER_IND_PARTITIONS 只查自己拥有的索引
如果查不到记录，不代表全好——得确认该索引确实有分区（比如范围/列表分区），全局索引不会出现在这个视图里

Oracle 对分区索引的 UNUSABLE 状态是“懒检查”：只要 SQL 没扫到那个坏分区，优化器就假装它存在；一旦执行计划触达，才在运行时报 ORA-01502。

典型场景：按时间分区的表，新数据只写最新分区，旧分区索引坏了但没人查，业务毫无感知
分区级 UNUSABLE 不影响其他分区，也不影响全局索引（如果建了的话）
DDL 操作如 ALTER TABLE ... DROP PARTITION 或 TRUNCATE PARTITION 后，对应分区索引默认变 UNUSABLE，这点极易被忽略

别一上来就 REBUILD 整个索引，又慢又锁表。精准重建坏分区更安全、更快。

重建完立刻查 DBA_IND_PARTITIONS 状态是 USABLE，但索引可能仍无法使用——常见于底层段损坏或统计信息过期。

重建后务必收集该分区的统计信息：DBMS_STATS.GATHER_INDEX_STATS 指定 partname 参数，否则优化器可能继续跳过它
如果重建失败并报 ORA-00604 或 ORA-01452，大概率是表空间满或临时表空间不足，不是索引本身问题
分区索引和表分区必须严格对齐：比如表用 RANGE 分区，索引也得是 LOCAL；若误建为全局索引，DBA_IND_PARTITIONS 根本不显示任何记录

分区索引的状态是“分而治之”的，查、修、验都得落到具体分区上，跨分区的假设基本都会翻车。