不需要改STATISTICS_LEVEL。正确方法是执行exec dbms_workload_repository.modify_snapshot_settings(interval=>0)，禁用自动快照但保留ASH、ADDM等诊断功能，无需重启且立即生效。
关闭 AWR 需要改 STATISTICS_LEVEL 吗？
不需要。把 statistics_level 设为 basic 确实会停掉 awr 快照采集，但这是“连带伤害”——它同时禁用自动内存管理（amm/asmm）、ash、addm、sql 监控、实时 sql 执行计划等关键诊断能力。这不是关闭 awr 的正解，而是自废武功。
真正可控、安全的关闭方式是停掉 AWR 快照生成本身，保留其他统计功能。核心操作只有一步：exec dbms_workload_repository.modify_snapshot_settings(interval=>0)。
-
interval=>0表示禁止自动创建快照，已有的历史快照仍可查 - 该操作无需重启实例，立即生效
- 若后续想恢复，默认间隔是 60 分钟（单位：分钟）
DBMS_WORKLOAD_REPOSITORY 修改后快照真停了吗？怎么验证
执行完 modify_snapshot_settings 后，必须手动确认是否生效，不能只信返回“PL/SQL 过程已成功完成”。常见误判是看到 DBA_HIST_SNAPSHOT 里还有数据，就以为没关掉——其实那是历史残留，不是新生成的。
验证方法分两步：
- 查当前设置：
SELECT snap_interval, retention FROM dba_hist_wr_control——snap_interval必须显示为+000000000 00:00:00.0（即 0 秒） - 等至少一个原定快照周期（比如原为 60 分钟），再查
SELECT MAX(snap_id) FROM dba_hist_snapshot，对比前后值是否增长 - 注意：
dba_hist_snapshot视图默认只对SELECT_CATALOG_ROLE或DBA可见，普通用户可能查不到
设成 BASIC 会引发哪些隐性故障？
把 STATISTICS_LEVEL 改成 BASIC 看似一劳永逸，实际在生产环境极易触发连锁问题：
- Oracle 11g+ 中，
MEMORY_TARGET或SGA_TARGET依赖该参数开启，设为BASIC后自动退化为手动内存管理，可能导致ORA-00832或内存争用加剧 - AWR 报告生成命令
@?/rdbms/admin/awrrpt.sql会直接报错ERROR: No snapshot data found，即使你只是想看旧数据 - 某些第三方监控工具（如 OEM、Zabbix 插件）依赖
V$ACTIVE_SESSION_HISTORY，而它在BASIC下不可用，导致指标断更 - 该参数是动态参数，但部分版本（如 12.1.0.2）在 RAC 环境下修改后需逐节点执行，否则出现节点间统计不一致
关闭 AWR 后，性能开销真的归零了吗？
不是。AWR 快照停了，但底层统计收集并未完全停止。Oracle 仍持续维护 V$SYSSTAT、V$SESSTAT、V$EVENTMETRIC 等动态视图，这部分开销约 1%–3% CPU，与 AWR 无关，也无法关闭。
真正能省下的，是快照写入 SYSAUX 表空间的 I/O 和归档压力——尤其是高频率采样（如每 5 分钟）或大库（>1000 个 session）场景下，WRH$_ 系列表的 INSERT 和索引维护明显拖慢 LGWR。
- 典型表现：
log file sync平均等待时间上升、db file sequential read在WRH$_LATCH上增多 - 可通过
SELECT event, time_waited_micro/1000000 sec FROM v$session_event WHERE event LIKE 'db file%'辅助定位 - 如果业务对延迟极度敏感（如金融交易库），建议同时禁用 SQL 计划捕获：
ALTER SYSTEM SET optimizer_capture_sql_plan_baselines=FALSE
复杂点在于：AWR 关停后，很多“症状”会滞后暴露，比如某天突然发现 DBA_HIST_SQLSTAT 数据断层，才意识到快照早停了但没人核验——这种静默失效最麻烦。
