自动分区维护任务未执行的主因是隐性开关未满足：窗口需ENABLED=TRUE、ACTIVE=TRUE且LAST_START_DATE为近期；auto index maintenance客户端须启用；索引需ORPHANED_ENTRIES=YES；STATISTICS_LEVEL≥TYPICAL且JOB_QUEUE_PROCESSES>0；PMO_DEFERRED_GIDX_MAINT_JOB有固定UTC时间触发。
自动分区维护任务没在窗口里跑，大概率不是“没配置”，而是被几层隐性开关拦住了。
查窗口是否真启用且活跃
很多人只看窗口名存在，就以为它在干活。其实 DBA_SCHEDULER_WINDOWS 里有三个关键字段必须同时满足：ENABLED = 'TRUE'、ACTIVE = 'TRUE'、LAST_START_DATE 是近期时间（比如过去24小时内）。如果 ACTIVE 是 FALSE，哪怕窗口开着，任务也不会触发。
- 执行
SELECT WINDOW_NAME, ENABLED, ACTIVE, LAST_START_DATE FROM DBA_SCHEDULER_WINDOWS WHERE WINDOW_NAME IN (SELECT WINDOW_NAME FROM DBA_SCHEDULER_WINGROUP_MEMBERS WHERE WINDOW_GROUP_NAME = 'MAINTENANCE_WINDOW_GROUP'); - 若某窗口
ACTIVE = FALSE，可能是上一个窗口还没关完（比如SATURDAY_WINDOW持续到周日凌晨2点，而SUNDAY_WINDOW在凌晨1点就开了），Oracle 不会重叠启动；可手动执行DBMS_SCHEDULER.CLOSE_WINDOW强制收尾 - 若
LAST_START_DATE是几天前的，说明窗口根本没成功打开过，得查alert.log里有没有ORA-27486: insufficient privileges或ORA-27475类错误
确认自动任务客户端是否启用
窗口只是“场地”，真正干活的是绑定在上面的“工人”——autotask client。统计信息收集对应的是 auto optimizer stats collection，但分区相关的索引异步维护（比如 PMO_DEFERRED_GIDX_MAINT_JOB）属于另一个独立 client，叫 auto index maintenance（19c 中默认启用，但可能被手动禁用）。
- 查状态：
SELECT CLIENT_NAME, STATUS, WINDOW_GROUP FROM DBA_AUTOTASK_CLIENT WHERE CLIENT_NAME LIKE '%index%'; - 如果返回
DISABLED，运行EXEC DBMS_AUTO_TASK_ADMIN.ENABLE('auto index maintenance', NULL, NULL); - 注意：这个 client 的启用状态不继承窗口组，必须单独开；它只在窗口内运行，但窗口开了它没开，照样不动
检查分区对象是否满足触发条件
自动索引维护不是“每个分区都扫一遍”，它只处理标记为 ORPHANED_ENTRIES = 'YES' 的全局索引。而这个标记只在你执行了 ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES 后才写入，且不会立刻触发后台作业——它要等下一个维护窗口到来，且该窗口里 auto index maintenance client 处于启用状态。
- 确认索引状态：
SELECT INDEX_NAME, STATUS, ORPHANED_ENTRIES FROM DBA_INDEXES WHERE TABLE_NAME = 'YOUR_PARTITIONED_TABLE'; - 如果
ORPHANED_ENTRIES = 'NO'，说明上次维护已清空，或压根没触发过UPDATE GLOBAL INDEXES选项 - 如果值是
YES但窗口过了还没动，再回头查 client 和窗口状态；别假设“只要写了 YES 就一定下一秒开始修”
别忽略 STATISTICS_LEVEL 和 JOB_QUEUE_PROCESSES
这两个参数是底层开关，一关全停。19c 要求 STATISTICS_LEVEL 至少为 TYPICAL（默认是 TYPICAL，但升级后可能被误设为 BASIC）；而 JOB_QUEUE_PROCESSES 必须 > 0，否则所有 scheduler job（包括 PMO_DEFERRED_GIDX_MAINT_JOB）直接被跳过。
- 查参数：
SHOW PARAMETER statistics_level;和SHOW PARAMETER job_queue_processes; - 若
statistics_level是BASIC，执行ALTER SYSTEM SET statistics_level = TYPICAL SCOPE=BOTH; - 若
job_queue_processes = 0，设为至少1000（高并发环境建议更高） - 改完不用重启实例，但要等下个窗口周期才生效
最常被漏掉的一点：PMO_DEFERRED_GIDX_MAINT_JOB 默认只在太平洋时间凌晨2点运行，和你的数据库时区无关。如果你数据库在东八区，它实际执行时间是北京时间上午10点——看着窗口开了，其实它根本没到点。查 NEXT_RUN_DATE 才知道它到底打算啥时候动。
