job_queue_processes为0是AWR自动快照停摆的直接原因；该参数为调度框架“电源开关”，设为0则DBMS_SCHEDULER及旧JOB任务（含AWR）静默停止，表现为dba_hist_snapshot长期无新增记录。
Job_Queue_Processes 为 0 是 AWR 自动快照停摆的直接原因
oracle 11g 的 awr 自动快照依赖后台调度框架，而 job_queue_processes 是该框架的“电源开关”。如果它被设为 0，所有基于 dbms_scheduler 或旧式 job 的自动任务（包括 awr 快照）都会静默停止，连日志都可能不报错——只表现为 dba_hist_snapshot 表长时间无新增记录。
如何确认 job_queue_processes 是否被禁用
别猜，直接查：
SHOW PARAMETER job_queue_processes
如果输出中 VALUE 列是 0，问题就在这里。常见诱因包括：
- 误执行过
ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH; - 数据库从低版本升级后未重置该参数（某些迁移脚本会显式清零）
- RAC 环境中某节点单独修改，导致局部失效
注意：job_queue_processes 和 statistics_level 必须同时满足条件：前者 > 0，后者必须是 TYPICAL 或 ALL。只改一个没用。
修改 job_queue_processes 后 AWR 还不启动？检查 autotask client 状态
参数生效只是第一步。AWR 快照由 autotask 框架驱动，而该框架是否启用，取决于 autotask client 的开关状态：
SELECT client_name, status FROM dba_autotask_client;
如果 auto optimizer stats collection 或 auto space advisor 显示 DISABLED，即使 job_queue_processes 正常，AWR 也不会触发。启用命令为：
EXEC DBMS_AUTO_TASK_ADMIN.ENABLE('auto optimizer stats collection', NULL, NULL);
关键点：
- 该操作需在
SYSAUX表空间可用、MMON进程存活的前提下执行 - 执行后不会立即生成快照，需等待下一个调度窗口（默认每小时整点）
- 若仍不生效，检查
dba_scheduler_windows中对应窗口（如MONDAY_WINDOW）是否ENABLED = 'TRUE'
为什么改了参数却看不到快照时间推进
常见错觉：改完 job_queue_processes 就该立刻出快照。实际不是。AWR 快照受三重节制：
-
dba_hist_wr_control中的interval（默认 60 分钟）决定采集频率 - 调度窗口（
dba_scheduler_windows）必须处于ACTIVE或即将OPEN状态 - MMON 进程本身不能卡死或挂起——若日志里反复出现
Slave action has been temporarily suspended，说明底层已故障，此时调参数只是“给瘫痪病人量血压”
最易被忽略的是：哪怕一切配置正确，如果 SYSAUX 表空间中 WRH$ 相关段因清理失败而严重膨胀，MMON 会在写入阶段超时退出，表面看就是“没反应”。先查 dba_segments 里 WRH$_% 占用，再动手。
