Oracle 19c AWR快照间隔过长导致失效，如何优化AWR保留策略和调整采样频率？

本文共计962个文字，预计阅读时间需要4分钟。

相关专题

awr快照不会因为“间隔过长”而失效——真正导致失效的，是间隔被设为 0（即完全关闭），或者后台进程 mmon 异常、sysaux 空间阻塞、绑定变量泛滥等底层故障。所谓“间隔过长”只是误判，实际问题往往藏在配置值或进程状态里。

怎么确认AWR快照是否真的“关了”？

关键看 dba_hist_wr_control 里的 SNAP_INTERVAL 值是不是 +00000 00:00:00.0：

• 如果是这个值，说明 AWR 快照采集已彻底禁用，不是“慢”，是“停”
• 如果是 +00000 01:00:00.0 或 +00000 00:30:00.0，说明采集正常，只是间隔设得长
• Oracle 19c 默认仍是每小时一次，retention 默认仍是 8 天（11520 分钟）

执行这条语句就能一眼看清：

SELECT dbid, snap_interval, retention FROM dba_hist_wr_control;

为什么有人觉得“调大间隔就失效”？

本质是混淆了“采样稀疏”和“功能失效”。比如把间隔从 60 分钟改成 24 小时，快照确实变少了，但只要 SNAP_INTERVAL 不是 0，MMON 就仍在运行，数据也仍在写入 WRH$ 表。问题出在：

• 分析时发现“没有覆盖问题时间段”的快照 → 其实是采样太粗，不是没生成
• 手动执行 DBMS_WORKLOAD_REPOSITORY.create_snapshot() 报错 → 错误根源在 MMON 或 SYSAUX，和间隔无关
• AWR 报告提示 “No data found for selected time period” → 很可能起止时间没对上快照边界，不是没快照

调整保留策略和采样频率的实操要点

改之前先确认当前负载和 SYSAUX 空间压力，避免盲目延长 retention 导致空间爆炸：

• 查 SYSAUX 实际占用：SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$_%' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY;
• 延长 retention 要同步评估空间：每多留 1 天，通常增加 0.5–2 GB（视活跃 SQL 数和绑定变量量而定）
• 缩短间隔（如到 15 分钟）只建议短期用：性能测试、问题复现期间，用完立刻调回，否则 WRH$_ACTIVE_SESSION_HISTORY 会暴涨
• Oracle 19c 支持 TOPNSQL 动态调整，但改它不影响快照生成，只影响 AWR 报告里 TOP SQL 的数量

执行修改的命令必须带单位（分钟）：

EXEC DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(interval => 30, retention => 14*24*60);

最容易被忽略的“假失效”信号

很多 DBA 看到 AWR 报告空白、快照 ID 断层、create_snapshot() 卡住，第一反应是“间隔设错了”，其实更该优先检查：

• v$bgprocess 中 MMON 的 SPID 是否为空 —— 空则进程已死，不是配置问题
• 告警日志里有没有 ORA-12751 —— 有则大概率是绑定变量泛滥卡在 wrh$_sql_bind_metadata
• dba_hist_snapshot 最后一条记录的 startup_time 是否变化 —— 若不变，说明实例重启过，新快照还没来得及生成
• SYSAUX 表空间中 WRH$ 段的分区数是否超 1000 —— 过多分区会让清理逻辑变慢甚至挂起

配置本身不会让 AWR 失效；失效永远发生在进程、内存、锁或空间层面。盯着 SNAP_INTERVAL 调来调去，不如先看 MMON 活着没、SYSAUX 堵没堵、x$kqlfbc 里有没有几万条绑定变量等着被扫。