sysaux表空间统计信息占用过高主因是wri$_optstat系列表或auto_stats_advisor_task日志突增，需先通过v$sysaux_occupants定位optimizer、sm/advisor等组件，再执行purge_stats、drop_advisor_task或shrink space（启用row movement后）安全清理，严禁truncate table。
SYSAUX表空间统计信息占用过高，八成是 WRI$_OPTSTAT 系列表或 AUTO_STATS_ADVISOR_TASK 日志在撑大空间，不是“慢慢长”，而是某几个对象突然膨胀——必须先定位再清理，不能直接删表。
查 v$sysaux_occupants 快速锁定统计类组件
这个视图比 dba_segments 更准、更快，直接告诉你哪个功能模块在吃空间：
- 执行
SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS gb FROM v$sysaux_occupants WHERE space_usage_kbytes > 0 ORDER BY space_usage_kbytes DESC; - 重点关注
OPTIMIZER（优化器统计历史）、SM/ADVISOR（统计信息顾问任务）和AUDSYS（统一审计，虽非统计但常被误判） - 若
SM/ADVISOR占几十 GB，大概率是WRI$_ADV_OBJECTS表及其索引在堆积体检报告，这类数据纯属诊断日志，无业务价值
确认 WRI$_OPTSTAT 表是否真在膨胀
统计信息历史默认保留 31 天，但频繁收集 + 直方图多 + BUG（如 19.26–19.28 的 BUG 38326922）会导致实际保留远超预期：
- 查当前保留天数：
SELECT dbms_stats.get_stats_history_retention FROM dual; - 查最老统计时间：
SELECT MIN(ctime) FROM sys.wri$_optstat_histhead_history;，若比保留天数早很多，就是 BUG 或清理卡住 - 看具体表大小：
SELECT segment_name, bytes/1024/1024/1024 AS gb FROM dba_segments WHERE segment_name LIKE 'WRI$_OPTSTAT%' AND tablespace_name = 'SYSAUX' ORDER BY bytes DESC; -
WRI$_OPTSTAT_HISTHEAD_HISTORY和WRI$_OPTSTAT_TAB_HISTORY是主力，单表超 5GB 就该干预
清理前必须关掉自动任务并验证版本风险
直接跑 DBMS_STATS.PURGE_STATS 可能失败或不生效，尤其在有已知 BUG 的版本中：
- 先停自动任务：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); - 检查版本是否命中
BUG 38326922：SELECT * FROM v$version WHERE banner LIKE '%Oracle Database%';，若为 19.26–19.28，优先打补丁或升级，否则清理可能反复失效 - 安全清理方式（非 DELETE）：
EXEC DBMS_STATS.PURGE_STATS(SYSDATE - 30);—— 指定时间点前的全部历史，不锁表、不爆 undo - 若
WRI$_ADV_OBJECTS是主因，用DBMS_STATS.DROP_ADVISOR_TASK('AUTO_STATS_ADVISOR_TASK');彻底干掉任务，比删数据更彻底
SHRINK SPACE 不生效？因为没开 ROW MOVEMENT
对 WRI$_OPTSTAT 类表做收缩，必须先启用行移动，否则报错或无效：
- 启用：
ALTER TABLE wri$_optstat_histhead_history ENABLE ROW MOVEMENT; - 收缩：
ALTER TABLE wri$_optstat_histhead_history SHRINK SPACE CASCADE; - 注意：收缩后需立刻收集统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'WRI$_OPTSTAT_HISTHEAD_HISTORY');，否则优化器可能仍按旧大小估算 - 别用
TRUNCATE TABLE—— 它会破坏 Oracle 内部一致性校验，引发ORA-00600错误
真正难处理的不是“怎么清”，而是“清完又涨”——根源常在未关闭的自动任务、未修复的 BUG、或误把 AUD$UNIFIED 当统计信息去清。每次清理后，务必用 v$sysaux_occupants 回检，盯住 OPTIMIZER 和 SM/ADVISOR 两项数值是否回落并稳定。
