AWR快照清理失败在Oracle 11g中几乎必然导致SYSAUX溢出，根本原因是DROP_SNAPSHOT_RANGE仅执行DELETE操作，不释放物理空间，高水位线（HWM）卡死不动，且受基线锁定、MMON卡死及分区HIGH_VALUE异常影响；必须配合FLUSH_AWR、DROP_BASELINE(cascade)或TRUNCATE PARTITION才能真正缩容。
awr快照清理失败在 oracle 11g 中几乎必然导致 sysaux 溢出，根本原因不是“没删”，而是“删了但空间不释放”——dbms_workload_repository.drop_snapshot_range 底层走的是 delete，不是 truncate，高水位线（hwm）卡死不动，表空间文件无法收缩。
drop_snapshot_range 只删元数据，不释放物理空间
调用 DROP_SNAPSHOT_RANGE 后，WRH$_ 表里对应快照的数据行被标记为“可覆盖”，但段的 HWM 不下降，dba_segments.bytes 值完全不变。哪怕 dba_free_space 显示有空闲块，Oracle 也无法在 HWM 上方分配新段——新快照写不进，ORA-1688 就来了。
-
WRH$_ACTIVE_SESSION_HISTORY这类按时间分区的大表，单个分区DELETE后仍占数 GB，而分区本身不会被自动DROP - 11g 没有 19c 的
flush_awr自动触发机制，MMON 默认每小时才跑一次清理，且极易被阻塞 - 执行完
DROP_SNAPSHOT_RANGE后必须立刻跟EXEC DBMS_WORKLOAD_REPOSITORY.FLUSH_AWR，否则等于白删
基线（Baseline）锁死快照是最隐蔽的元凶
11g 中，STATIC 或配置不当的 MOVING_WINDOW 基线会强制保留其时间范围内的所有快照，完全无视 retention 设置。一旦基线起始快照 ID 是建库初期（如 1 或 2），而结束 ID 接近当前最大值，几百个快照就被钉住不动。
- 查锁定范围：
SELECT baseline_name, baseline_type, start_snap_id, end_snap_id FROM dba_hist_baseline_details -
DROP_BASELINE必须加cascade => TRUE，否则只删元数据，物理数据还在原分区里躺着 - 基线优先级高于快照策略，只要它存在，自动清理就绕不开它
MMON 卡死或分区 HIGH_VALUE 异常让清理彻底失效
11g 特有的绑定变量缺陷会让 MMON 在扫描内存基表 x$kqlfbc 时超时卡死，表现为 WRH$_SQL_BIND_METADATA 持续增长、报 ORA-12751: cpu time violation；同时，某些场景下分区的 HIGH_VALUE 与实际数据脱节，导致自动清理逻辑判断“还没过期”，跳过本该删的分区。
- 验证 MMON 是否卡死：
SELECT * FROM v$bgprocess WHERE pname = 'MMON'—— 无返回或spid为空即异常 - 临时止血：
ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'WRH$_SQL_BIND_METADATA' SCOPE=BOTH - 查异常分区：
SELECT table_name, partition_name, TO_DATE(REGEXP_SUBSTR(high_value,'[0-9]+'),'J') partition_date FROM dba_tab_partitions WHERE table_name LIKE 'WRH$%' AND TO_DATE(REGEXP_SUBSTR(high_value,'[0-9]+'),'J')
真正释放空间的关键动作不是删快照，而是清分区——ALTER TABLE wrh$_active_session_history TRUNCATE PARTITION ... 才能秒级降 HWM；但操作前必须确认分区名不是系统管理分区（如 WRH$_ACTIVE_SES_MXDB_MXSN），否则可能破坏 AWR 完整性。
