Oracle 11g AWR自动清理失效的根本原因是MMON未触发DROP_SNAPSHOT_RANGE，需手动执行该过程并配合设置_swrf_test_action=72、检查基线锁定及验证MMON状态。
oracle 11g 的 awr 自动清理经常“假装在工作”：保留策略明明设了 8 天，dba_hist_wr_control 显示一切正常，但 wrh$_active_session_history 等表持续膨胀，sysaux 占用飙到 20gb+，而 min(snap_id) 还停留在几个月前——这基本不是配置错了，而是自动 purge 任务根本没跑起来。
为什么 dbms_workload_repository.drop_snapshot_range 是最直接的修复入口
AWR 自动清理底层依赖的是 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE 这个存储过程，它才是真正删数据的执行者。MMON 调度失败、分区元数据卡住、或 BUG（如 MOS Doc ID 14084247）都会导致该过程不被触发，但你可以绕过调度，手动调它。
- 必须用
SYS用户执行，普通 DBA 权限不够 - 参数顺序固定：
low_snap_id、high_snap_id、dbid；漏掉dbid会报ORA-13516 - 执行前务必确认快照范围是否安全：先查
select min(snap_id), max(snap_id), dbid from wrh$_sysstat; - 一次别删太多（建议单次 ≤ 500 个快照），避免锁表时间过长或归档暴增
_swrf_test_action = 72 是触发分区清理的关键开关
在 Oracle 11.2.0.3+ 中，AWR 表分区常出现“HIGH_VALUE 过期但数据不释放”的粘连现象。此时即使调了 drop_snapshot_range，底层仍可能跳过物理删除。设置隐含参数 _swrf_test_action = 72 是强制刷新分区元数据的信号量。
- 仅对当前 session 生效，需在调用
drop_snapshot_range前执行：alter session set "_swrf_test_action" = 72; - 不能设成系统级（
SCOPE=BOTH），否则可能干扰 MMON 正常行为 - 执行后立刻查
dba_tab_partitions，应能看到旧分区被标记为INVALID或已消失 - 该操作本身不删数据，只是“松开刹车”，后续
drop_snapshot_range才能真正落地
基线（Baseline）是静默阻止清理的常见原因
很多人忽略一点：只要一个快照被任何基线引用，哪怕已超保留期，drop_snapshot_range 也会跳过它，并且不报错。结果就是清理看似成功，实际“漏删”。
- 查基线覆盖范围：
SELECT baseline_name, start_snap_id, end_snap_id FROM dba_hist_baseline_details; - 临时解除基线锁定（如非生产关键基线）：
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'YOUR_BASELINE', cascade => TRUE); - 若必须保留基线，可先用
modify_baseline_window_size缩小其窗口，再清理 - 注意：11g 中基线优先级高于 retention 策略，这是和 19c 最大的行为差异
清理后必须验证 MMON 是否恢复自驱能力
手动清完只是止血，如果 MMON 仍不自动跑，下次还会复发。重点看两个信号：
- 检查 MMON 是否活跃：
SELECT pid, spid, program FROM v$process WHERE program LIKE '%MMON%';—— 若无结果或状态异常（如PADDR = 00），需重启它 - 最快重启方式：
ALTER SYSTEM SET "_swrf_mmon_flush" = FALSE; ALTER SYSTEM SET "_swrf_mmon_flush" = TRUE; - 验证自动清理是否回归：等 1–2 小时后，查
select * from dba_hist_wr_control where last_purge_time > sysdate - 1/24; - 别信
awrinfo.sql的 summary，它常缓存旧状态；以dba_hist_snapshot的实时max(snap_id)为准
真正麻烦的从来不是“怎么删”，而是删完发现 WRH$_SQL_BIND_METADATA 因绑定变量堆积又把 MMON 拖垮——那得回到 v$sql_bind_capture 查大户，再决定要不要禁用它的刷新。手动清理只是把数据库从 ICU 推回病房，病根还得一层层剥。
