awr默认配置不适用生产环境，需手动调整快照频率和保留时长；查dba_hist_wr_control获真实配置，修改用dbms_workload_repository.modify_snapshot_settings，单位均为分钟；topnsql影响sql捕获量与addm分析深度；rac下需全局同步确认节点状态。
awr 默认配置在大多数生产场景下都不够用，必须手动调整快照频率和保留时长，否则关键性能尖刺会被漏掉、历史数据过早被清理。
如何查看当前 AWR 快照配置
直接查 dba_hist_wr_control 是唯一可靠方式，别信文档里写的“默认 60 分钟”。实际值可能被之前的人改过，或者因补丁/升级漂移。
-
SELECT snap_interval, retention FROM dba_hist_wr_control;—— 注意snap_interval是INTERVAL DAY TO SECOND类型，不能直接读数字；用EXTRACT(hour FROM snap_interval)拆解更安全 - 常见误判：看到
retention = +00000 08:00:00:00就以为是 8 天，但单位是「天:小时:分钟:秒」，真实保留期是 8 天整，不是 192 小时 - RAC 环境下，该视图返回的是全局配置，所有实例共用同一套参数，不按节点单独生效
修改 AWR 快照间隔和保留时间
用 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 设置，interval 单位是分钟，retention 单位是分钟（不是天）—— 这是最容易填错的地方。
- 把快照从 60 分钟缩到 15 分钟：
interval => 15，不是interval => '0 0:15:0' - 把保留期从 8 天（11520 分钟）扩到 31 天：
retention => 44640（31×24×60），不是31或'31' - 如果只改某一个 PDB 的配置，必须显式传入
dbid参数，否则修改的是 CDB 级别配置；查 PDB 的dbid用SELECT dbid FROM v$pdbs WHERE name = 'MY_PDB'; - 执行后立即生效，无需重启实例，但新设置只对后续生成的快照起作用，已存在的快照不会被重采样
为什么 topnsql 参数值得特别关注
topnsql 控制每个快照里捕获的 TOP SQL 数量，默认是 30 条。它不只影响报告里“SQL Statistics”章节的丰富度，还直接影响 ASH 数据聚合粒度和 ADDM 的分析深度。
- 设太低（如 10）：高并发 OLTP 场景下，大量中等耗时 SQL 被截断，ADDM 可能报“未发现明显瓶颈”，其实是数据没抓全
- 设太高（如 100）：快照体积显著增大，尤其当 SQL 文本长、绑定变量多时，
dba_hist_sqltext和dba_hist_sqlstat表膨胀很快，备份和导出变慢 - Oracle 19c 实测建议值：OLTP 系统设 50，报表类系统设 30；若启用了 SQL Plan Directives 或 SQL Management Base，建议同步调高
topnsql避免计划统计失真
RAC 环境下修改 AWR 配置的隐藏风险
RAC 不是简单地“多个单实例叠加”，AWR 配置修改后，各节点快照时间点未必严格对齐，尤其在跨节点故障恢复后。
- 执行
MODIFY_SNAPSHOT_SETTINGS后，立刻在所有节点上运行SELECT instance_name, startup_time FROM gv$instance;，确认没有节点处于 crash recovery 状态；否则新配置可能只在部分节点生效 - 不要在 RAC 中单独停某个节点的 AWR 收集（比如用
ALTER SYSTEM SET statistics_level = BASIC），这会导致gv$active_session_history视图在该节点无数据，ASH 整合报告出现断层 - 重建 AWR（如执行
catawr.sql）在 RAC 下必须在所有节点上串行执行，且需先关闭 CRS 资源，否则dba_hist_snapshot序列号会错乱，后续报告时间范围识别失败
配置不是一劳永逸的事——快照频率和保留策略要随业务峰值周期动态调整，比如大促前拉高采集密度，大促后及时缩容避免归档压力；topnsql 值也得配合 SQL 审计策略定期回顾，否则很容易变成“看起来在监控，其实什么也没抓住”。
