删除分区时必须加 UPDATE GLOBAL INDEXES，否则全局索引立即变为UNUSABLE导致ORA-01502；该子句保持索引VALID但标记ORPHANED_ENTRIES=YES，由后台任务异步清理，也可手动调用CLEANUP_GIDX或重建索引。
删除分区时必须加 UPDATE GLOBAL INDEXES
不加这个子句，全局索引立刻变成 UNUSABLE 状态，后续所有依赖该索引的 DML（如 INSERT、UPDATE）或查询都会报 ORA-01502。本地索引不受影响，但全局索引——尤其是主键、唯一约束背后的索引——必须显式保护。
常见错误写法：ALTER TABLE t DROP PARTITION p1 或 ALTER TABLE t TRUNCATE PARTITION p1，两者都默认让全局索引失效。
-
DROP PARTITION和TRUNCATE PARTITION都支持UPDATE GLOBAL INDEXES，语法一致 - 不能用
UPDATE INDEXES（那是给本地索引用的），必须写全UPDATE GLOBAL INDEXES - 索引组织表（IOT）不支持该子句，需改用其他策略（如先清空再删分区）
UPDATE GLOBAL INDEXES 不等于“立刻重建索引”
在 Oracle 12c 及以后（包括 19c），加上 UPDATE GLOBAL INDEXES 后，索引状态保持 VALID，但内部会标记为 ORPHANED_ENTRIES = YES —— 意味着索引条目还没真正清理，只是逻辑上“暂不生效”。真正的清理由后台任务 PMO_DEFERRED_GIDX_MAINT_JOB 异步完成，默认每天太平洋时间凌晨 2:00 执行。
这意味着：DDL 执行快，业务不卡顿；但索引“可用”是带条件的——它能走，但可能包含已删除分区的残留条目（不影响正确性，Oracle 会在执行时自动过滤），直到维护任务跑完才彻底干净。
- 查状态用：
SELECT TABLE_NAME, INDEX_NAME, STATUS, ORPHANED_ENTRIES FROM dba_indexes WHERE ORPHANED_ENTRIES = 'YES' - 任务信息查：
SELECT JOB_NAME, NEXT_RUN_DATE FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'PMO_DEFERRED_GIDX_MAINT_JOB' - 如果业务不允许延迟清理（比如 24 小时运行），必须手动触发或立即重建
手动维护全局索引的三种实用方式
异步任务虽省心，但在高负载或 SLA 严格的系统中，不能等凌晨两点。以下操作建议在低峰期执行，并注意 redo 日志和锁影响：
- 调用清理过程：
EXEC DBMS_PART.CLEANUP_GIDX('OWNER', 'TABLE_NAME')—— 清理指定表关联的所有游离全局索引条目 - 立即运行维护任务：
EXEC DBMS_SCHEDULER.RUN_JOB('PMO_DEFERRED_GIDX_MAINT_JOB')—— 全局生效，但会阻塞一段时间 - 直接重建索引：
ALTER INDEX idx_name REBUILD ONLINE PARALLEL 4—— 最彻底，但耗资源；若空间紧张，可先设NOLOGGING（ALTER INDEX idx_name NOLOGGING），完成后切回LOGGING
注意：REBUILD ONLINE 期间表仍可读写，但会显著增加 I/O 和 undo 表空间压力；COALESCE CLEANUP（如 ALTER INDEX idx_name COALESCE CLEANUP PARALLEL 8）适合碎片化严重场景，但不是所有版本都支持。
为什么有时加了 UPDATE GLOBAL INDEXES 还报 ORA-01502？
最常见原因是：你确实加了，但执行后没检查索引状态，或者误以为“加了就万事大吉”，结果在维护任务跑完前就插入了违反唯一约束的数据（比如重复值刚好落在被删分区的旧索引条目范围内）。Oracle 虽然过滤了无效条目，但唯一性校验仍可能因延迟清理而短暂失准。
另一个隐蔽坑点：多个分区连续删除时，每个 ALTER TABLE 语句都必须单独带 UPDATE GLOBAL INDEXES。写成批量脚本容易漏掉，比如：
ALTER TABLE t DROP PARTITION p1;<br>ALTER TABLE t DROP PARTITION p2 UPDATE GLOBAL INDEXES; -- 只有第二句生效，p1 导致索引已失效
更稳妥的做法是：单次操作只删一个分区，且每条 DDL 都显式带上 UPDATE GLOBAL INDEXES；或用 PL/SQL 循环封装，确保一致性。
