AWR快照清理失败主因是drop_snapshot_range仅删除元数据、不释放物理空间，且受基线锁定、MMON卡死及分区HIGH_VALUE异常影响；必须配合flush_awr、DROP_BASELINE（cascade）或TRUNCATE PARTITION才能真正缩容。
awr快照清理失败在oracle 11g中几乎必然导致sysaux爆满，根本原因不是“没删”，而是“删了但空间不释放”——delete操作残留高水位线（hwm），且分区清理逻辑被基线或mmon卡死。
为什么DBMS_WORKLOAD_REPOSITORY清理后SYSAUX仍不缩容
调用DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE或依赖自动清理，底层走的是DELETE语句，不是TRUNCATE。这意味着：
- 数据行被标记为“可覆盖”，但段的高水位线（HWM）纹丝不动，
dba_segments.bytes值不变 - 表空间文件不会自动收缩，即使
dba_free_space显示有空闲块，Oracle也无法在HWM之上分配新段 - 对
WRH$_ACTIVE_SESSION_HISTORY这类按时间分区的大表，单个分区DELETE后仍占数GB，而分区本身无法被DROP（除非手动TRUNCATE PARTITION）
基线（Baseline）锁死快照是11g最隐蔽的元凶
Oracle 11g中，STATIC或配置不当的MOVING_WINDOW基线会强制保留其时间范围内的所有快照，完全无视retention设置：
- 查基线锁定范围：
SELECT baseline_name, baseline_type, start_snap_id, end_snap_id FROM dba_hist_baseline_details; - 若
start_snap_id是建库初期（如1或2），而end_snap_id接近当前最大值，说明几百个快照被钉住 -
DROP_BASELINE(... cascade => TRUE)必须加cascade，否则只删元数据，物理数据还在
MMON进程卡在x$kqlfbc导致WRH$_SQL_BIND_METADATA堆积
这是11g特有的绑定变量处理缺陷：当应用SQL使用超量绑定变量（单条>5000个），MMON扫描内存基表x$kqlfbc会超时，直接卡住整个AWR刷新链路：
- 现象：
WRH$_SQL_BIND_METADATA表持续增长，伴随ORA-12751: cpu time violation - 验证是否卡死：
SELECT * FROM dba_hist_wr_control WHERE disabled_flush_tables LIKE '%BIND%';返回空即表示仍在尝试插入 - 临时解法（立即生效）：
ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'WRH$_SQL_BIND_METADATA' SCOPE=BOTH;
分区HIGH_VALUE异常让自动清理彻底失效
11g AWR分区表（如WRH$_ACTIVE_SESSION_HISTORY）依赖HIGH_VALUE判断过期，但某些场景下该值与实际数据脱节：
- 查过期但未清理的分区：
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') - 若结果中存在
partition_date远早于当前日期，但分区仍存在，说明MMON跳过了该分区（常见于实例重启后MMON初始化失败） - 此时不能等自动清理，必须人工
ALTER TABLE WRH$_ACTIVE_SESSION_HISTORY TRUNCATE PARTITION;
真正棘手的地方在于：这四类问题常同时发生。比如一个STATIC基线锁住快照，导致MMON在清理WRH$_SQL_BIND_METADATA时反复重试超时，最终让WRH$_ACTIVE_SESSION_HISTORY的分区HWM越堆越高——你看到的是空间爆满，根子却横跨基线策略、内存扫描、分区元数据、段管理四个层面。
