如何监控AWR数据收集Job_DBA_SCHEDULER_JOBS中的BSLN_MAINTAIN

BSLN_MAINTAIN_STATS状态需查DBA_SCHEDULER_JOBS中含'%BSLN%MAINTAIN%STATS%'的作业，若无结果则可能被禁用或功能未启用；还需确认维护窗口、AWR快照、statistics_level参数及磁盘空间是否正常。

查 Job_DBASCHEDULER_JOBS 里 BSLN_MAINTAIN_STATS 的状态

这个 job 不是普通 dba_scheduler_job，它由 oracle 自动创建、受 dbms_workload_repository 和 dbms_server_alert 内部调度控制，直接查 dba_scheduler_jobs 可能看不到——它实际注册在 dba_scheduler_jobs 中但名字带前缀或被过滤。更稳的方式是查底层视图：

SELECT job_name, state, last_start_date, next_run_date FROM dba_scheduler_jobs WHERE job_name LIKE '%BSLN%MAINTAIN%STATS%';
如果没结果，说明 job 已被禁用或未启用（常见于 AWR 关闭、baseline 功能关闭、或数据库版本低于 11.2.0.4）
注意：BSLN_MAINTAIN_STATS 在 12c+ 默认归入 MAINTENANCE_WINDOW_GROUP，需确认维护窗口是否开启：SELECT window_name, enabled FROM dba_scheduler_windows WHERE window_name IN (SELECT window_name FROM dba_scheduler_wingroup_members WHERE group_name = 'MAINTENANCE_WINDOW_GROUP');

确认 BSLN_MAINTAIN_STATS 是否真在运行

即使 job 显示 ENABLED，也不代表它每次都会执行成功。它依赖两个前置条件：AWR 快照必须存在，且 baseline 统计信息需要更新（比如新 baseline 被创建、旧 baseline 过期、或 stats_history 被清理）。典型错误现象：

job 状态为 COMPLETED，但 DBA_HIST_BASELINE 中的 last_refresh_time 长期不变
日志中报错 ORA-13516: AWR snapshot range is invalid —— 说明 AWR 没有足够快照供 baseline 统计计算
job 执行时长极短（

验证方式：查最近一次运行详情：SELECT log_date, status, additional_info FROM dba_scheduler_job_log WHERE job_name LIKE '%BSLN%MAINTAIN%STATS%' ORDER BY log_date DESC FETCH FIRST 5 ROWS ONLY;

手动触发并观察行为

不能靠 DBMS_SCHEDULER.ENABLE 或 RUN_JOB 直接触发它——Oracle 明确禁止手动调用该 job。正确做法是模拟它的触发条件：

强制生成一个新 AWR 快照：EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
新建一个 baseline：EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id => X, end_snap_id => Y, baseline_name => 'test_bsl');
等 1–2 分钟后检查 DBA_HIST_BASELINE.last_refresh_time 是否更新
若仍不更新，检查参数：SELECT name, value FROM v$parameter WHERE name IN ('statistics_level', 'awr_snapshot_time_offset'); —— statistics_level 必须为 TYPICAL 或 ALL，否则 baseline 统计无法采集

监控长期失效的信号点

最易被忽略的是 baseline 统计“静默失效”：job 每次都跑，但只刷新空数据。关键看 DBA_HIST_BASELINE_STATISTICS 表是否有新增记录：

SELECT COUNT(*) FROM dba_hist_baseline_statistics WHERE baseline_id IN (SELECT baseline_id FROM dba_hist_baseline) AND snap_id > (SELECT MAX(snap_id)-10 FROM dba_hist_snapshot);
如果返回 0，说明近 10 个快照内没写入任何 baseline 统计，job 形同虚设
此时要查 v$sysmetric 中 Baseline Statistics Refresh Rate Per Second 指标是否持续为 0（需启用企业管理器或自定义 SQL 查询）
还有一种情况：DBA_HIST_BASELINE 中 moving_window_baseline 的 last_refresh_time 停滞，而其他 baseline 正常——说明 moving window baseline 的刷新逻辑被阻断（通常因 db_recovery_file_dest_size 不足导致 AWR 快照被自动清理）

baseline 统计不是“开个 job 就完事”，它卡在 AWR、参数、磁盘空间、窗口策略四层交界处，漏掉任意一层，监控就变成盲区。