ORA-01502的根本原因是全局索引（尤其唯一索引）在DROP/EXCHANGE/SPLIT PARTITION后被Oracle静默标记为UNUSABLE，非报错失败而是“成功执行但索引已坏”，后续DML触发该错误；非唯一索引失效仅影响查询性能，唯一索引失效则直接阻断INSERT/UPDATE。
为什么分区操作后立刻报ORA-01502
根本原因是全局索引（尤其是唯一索引）在DROP PARTITION、EXCHANGE PARTITION、SPLIT PARTITION等操作后被Oracle静默标记为UNUSABLE——不是报错失败，而是“成功执行但索引已坏”。后续任何涉及该索引的DML（特别是INSERT/UPDATE主键或唯一键字段）都会触发ORA-01502。
关键点在于：Oracle默认不维护全局索引，是为了避免DDL期间锁表和I/O风暴。它把选择权交给你，而不是替你扛。
- 非唯一索引失效：查询可能变慢，但DML通常还能跑
- 唯一索引（含主键索引）失效：DML直接卡死，这是
ORA-01502最常出现的场景 -
TRUNCATE PARTITION不支持UPDATE GLOBAL INDEXES，只能事后重建
执行前必须检查的三件事
别急着重建或加子句，先确认当前状态。很多误操作源于没看清索引本身已处于中间态。
- 查索引整体状态：
SELECT index_name, status, funcidx_status FROM user_indexes WHERE table_name = 'YOUR_TABLE';—— 如果已有UNUSABLE，加UPDATE GLOBAL INDEXES也救不回来 - 查分区级状态（对分区索引）：
SELECT index_name, partition_name, status FROM user_ind_partitions WHERE index_name IN (SELECT index_name FROM user_indexes WHERE table_name = 'YOUR_TABLE'); - 查最近DDL日志：
SELECT sql_text, timestamp FROM dba_audit_trail WHERE action_name IN ('DROP TABLE','ALTER TABLE') AND timestamp > SYSDATE - 1 ORDER BY timestamp DESC;确认是不是刚执行过DROP/EXCHANGE
修复时选REBUILD还是UPDATE GLOBAL INDEXES
取决于你正在做什么、能不能停业务、索引有多大。
- 已经报错且业务中断：优先用
ALTER INDEX idx_name REBUILD（在线加ONLINE可减少锁）；若索引是分区的，用ALTER INDEX idx_name REBUILD PARTITION part_name - 还没执行分区操作，但知道要动：加
UPDATE GLOBAL INDEXES子句，例如ALTER TABLE t DROP PARTITION p_old UPDATE GLOBAL INDEXES; - 表是TB级、索引数据量大、写入频繁：别加
UPDATE GLOBAL INDEXES，它会导致DDL时间飙升甚至超时；改用分步法——先DROP，再REBUILD，并安排在低峰期 - 注意：
UPDATE GLOBAL INDEXES对TRUNCATE PARTITION无效，必须重建
容易被忽略的硬伤点
很多DBA修完就上线，结果几小时后又崩——问题不在操作本身，而在边界条件。
- 索引重建过程中被中断（比如会话kill、实例崩溃），Oracle只回滚表结构变更，不回滚索引修复动作，状态会卡在
UNUSABLE或INPROGRESS，必须手动清理 -
SKIP_UNUSABLE_INDEXES=true只是绕过错误，不能解决唯一性校验缺失的问题，线上环境慎用 - 本地索引（
LOCAL）不受UPDATE GLOBAL INDEXES影响，它的分区失效只影响对应分区查询，但不会导致全局DML失败 - 如果索引所在表空间是
READ ONLY，REBUILD会失败，得先切回READ WRITE
