加update global indexes不等于索引立刻可用，仅标记为valid但orphaned_entries=yes，存在数据一致性风险；必须手动执行cleanup_gidx并确认该字段为no才算完成。
加 UPDATE GLOBAL INDEXES 不等于索引立刻可用
直接在 DROP PARTITION 或 TRUNCATE PARTITION 后加 UPDATE GLOBAL INDEXES，确实能防止索引状态变成 UNUSABLE，但别以为这就万事大吉了。Oracle 19c 只是把索引标记为 VALID，同时在 DBA_INDEXES.ORPHANED_ENTRIES 字段设为 YES——意味着有“游离条目”没清理，查询可能返回错误结果，尤其涉及唯一约束或精确等值查找时。
这个状态不报错、不阻断 SQL 执行，但数据一致性已悄悄受损。后台默认靠 PMO_DEFERRED_GIDX_MAINT_JOB 每天凌晨 2:00（太平洋时间）自动清理，生产环境基本不能等。
删分区前必须做的三件事
跳过任意一步，全局索引就处于“假活”状态：
- 语句里必须带
UPDATE GLOBAL INDEXES—— 不加会直接触发ORA-01502，所有走该索引的查询全部失败 - 提前执行
ALTER INDEX idx_name NOLOGGING（如业务允许丢失日志）—— 否则维护过程产生巨量 Redo，拖慢主备同步 - 业务低峰期手动运行
DBMS_PART.CLEANUP_GIDX('SCHEMA', 'TABLE_NAME')—— 避免依赖默认调度，也比DBMS_SCHEDULER.RUN_JOB('PMO_DEFERRED_GIDX_MAINT_JOB')更可控，不会引发突发 Redo 峰值
LOCAL 索引完全不用加 UPDATE GLOBAL INDEXES
本地索引跟分区绑定，删分区时对应索引分区自动跟着删，不会失效。对 LOCAL 索引执行 ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES 会直接报错：alter index and alter partition may not be combined。
如果表同时有 GLOBAL 和 LOCAL 索引，UPDATE GLOBAL INDEXES 只影响前者，后者不受干扰。但很多人误以为加了就“全保住了”，结果发现本地索引部分根本没被处理——其实它压根不需要。
别忽略 ORPHANED_ENTRIES = YES 这个静默陷阱
这个字段值为 YES 时，索引仍显示 VALID，SQL 看似一切正常，但实际已埋下隐患：某次唯一键插入突然报错、某条 WHERE id = ? 查询漏掉数据、统计信息偏差变大……问题往往在数周后才暴露。
CLEANUP_GIDX 手动执行常被当成“可选优化”，但它不是锦上添花，而是必要闭环。只要删过带全局索引的分区，就得查一次 DBA_INDEXES.ORPHANED_ENTRIES，确认为 NO 才算真正完成。
