Oracle 12c全局索引异步维护默认启用且不可关闭，执行DROP/TRUNCATE PARTITION加UPDATE GLOBAL INDEXES即触发；ORPHANED_ENTRIES='YES'且STATUS='VALID'为生效标志；支持CLEANUP_GIDX、COALESCE CLEANUP和REBUILD三种手动清理方式，但仅限堆表、非SYS用户、无域索引等受限场景。
oracle 12c 的异步全局索引维护不是靠 async 模式开关控制的，它默认启用且无法关闭——只要你在 drop partition 或 truncate partition 时显式加上 update global indexes，数据库就会自动走异步路径。
为什么没有 ASYNC 关键字？
你查不到 UPDATE GLOBAL INDEXES ASYNC 这种语法，因为 Oracle 并未提供该关键字。所谓“异步”是 12.1 起的默认行为升级：以前加 UPDATE GLOBAL INDEXES 会立刻重建索引条目（阻塞、耗时）；现在它只标记元数据，把实际清理延迟到后台作业执行。
- 所有支持的 DDL（
ALTER TABLE ... DROP/TRUNCATE PARTITION ... UPDATE GLOBAL INDEXES）都默认异步 - 不加
UPDATE GLOBAL INDEXES会导致全局索引直接变为UNUSABLE，这不是异步，是失效 - 试图写
UPDATE GLOBAL INDEXES ASYNC会报错ORA-00922: missing or invalid option
ORPHANED_ENTRIES = 'YES' 是异步发生的明确信号
执行完带 UPDATE GLOBAL INDEXES 的分区操作后，立即查 DBA_INDEXES 或 USER_INDEXES，如果看到 ORPHANED_ENTRIES = 'YES'，就说明异步已生效，索引仍为 VALID，但残留了指向已删分区的“孤儿条目”：
SELECT index_name, status, orphaned_entries FROM user_indexes WHERE table_name = 'T_PART';
-
STATUS = 'VALID'+ORPHANED_ENTRIES = 'YES'→ 异步已触发，索引可用但未清理 -
STATUS = 'UNUSABLE'→ 你漏写了UPDATE GLOBAL INDEXES，或操作对象不满足条件（如对象表、域索引、SYS 用户下对象） - 该列在 12.1+ 才存在，是判断异步是否起效最直接的依据
三种手动触发清理的方式及其适用场景
异步不等于不管——后台作业 SYS.PMO_DEFERRED_GIDX_MAINT_JOB 默认每天凌晨 2 点运行，但业务不允许等那么久时，得主动干预：
-
EXEC DBMS_PART.CLEANUP_GIDX('SCHEMA_NAME', 'TABLE_NAME');：推荐首选。只清理当前表涉及的全局索引孤儿条目，影响范围最小，适合单表紧急维护 -
ALTER INDEX idx_name COALESCE CLEANUP;：比全量REBUILD轻量，仅扫描并清除孤儿项，不重排索引结构，适合高可用要求场景 -
ALTER INDEX idx_name REBUILD;：彻底重建，清除孤儿且优化物理结构，但会锁索引、耗资源，慎用于生产高峰
注意：COALESCE CLEANUP 和 CLEANUP_GIDX 都不会改变索引统计信息，后续需手动 DBMS_STATS.GATHER_INDEX_STATS。
容易被忽略的兼容性与限制点
异步维护看似开箱即用，但几个硬性限制常导致意外失败：
- 仅适用于堆表（
HEAP），不支持索引组织表（IOT）、对象类型表、XMLType 表 - 不支持含域索引（
DOMAIN INDEX）或函数索引的全局索引 -
SYS用户下的表/索引无法使用该特性（会报ORA-20000: Global index maintenance is not supported for SYS objects） - 若表上有
ENABLE VALIDATE的外键引用该分区键，TRUNCATE PARTITION即使加UPDATE GLOBAL INDEXES也会报错
真正关键的不是“怎么开启异步”，而是确认你的表结构、索引类型和用户权限完全落在支持范围内——否则看似写了 UPDATE GLOBAL INDEXES，实际仍会退化为同步重建或直接报错。
