sysaux表空间增长过快主因是sm/advisor、audsys、sm/optstat及19c asts等少数组件异常占用，需先用v$sysaux_occupants定位top占用者，再针对性清理任务或调整配置，避免盲目truncate或加数据文件。
SYSAUX表空间增长过快，八成不是均匀膨胀，而是某几个内部组件在“ silently eat space”——最常背锅的是 SM/ADVISOR、AUDSYS、SM/OPTSTAT 和 19c 新增的 ASTS（如 WRI$_SQLSET_PLAN_LINES）。
查占用大户：用 v$sysaux_occupants 快速定位真凶
别一上来就 TRUNCATE 或加数据文件。先看谁占得最多，这个视图比 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; - 重点关注：
SM/ADVISOR（统计顾问日志）、AUDSYS（统一审计）、SM/OPTSTAT（优化器统计历史）、SM/ADVISOR在 19.7 默认开启，但 19.8+ 已默认关闭；若它占几十 GB，大概率是WRI$_ADV_OBJECTS或WRI$_SQLSET_PLAN_LINES这类 LOB 表撑爆的 -
AUDSYS排前三？说明AUD$UNIFIED没清理，不能查AUD$，得查AUDSYS.AUD$UNIFIED
清 SM/ADVISOR：删任务比删表更安全
WRI$_ADV_OBJECTS 占几十 GB？它只是 AUTO_STATS_ADVISOR_TASK 的日志表，非业务数据，但直接 TRUNCATE 可能锁表或触发递归 DDL 错误：
- 优先用
DBMS_STATS.DROP_ADVISOR_TASK('AUTO_STATS_ADVISOR_TASK')—— 删除任务本身，后续不再写入，历史数据也会随自动清理逻辑逐步释放 - 若版本 ≥19.26 且 prvt_advisor.delete_expired_tasks
- 禁用后建议检查参数：
SELECT name, value FROM wri$_adv_parameters WHERE task_id IN (SELECT id FROM wri$_adv_tasks WHERE name = 'AUTO_STATS_ADVISOR_TASK') AND name IN ('DAYS_TO_EXPIRE', 'EXECUTION_DAYS_TO_EXPIRE');
调 SM/OPTSTAT：改保留策略比删历史更治本
优化器统计信息历史（WRI$_OPTSTAT_* 表）长期堆积，尤其在频繁 dbms_stats.gather_* 的库中：
- 查当前保留天数：
SELECT dbms_stats.get_stats_history_retention FROM dual;（默认 31 天） - 缩短期限（例如设为 7 天）：
EXEC dbms_stats.alter_stats_history_retention(7); - 立即清理过期数据：
EXEC dbms_stats.purge_stats(SYSDATE - 7); - 若表仍很大，可考虑在线重建：
CREATE TABLE WRI$_OPTSTAT_HISTGRM_HISTORY_B AS SELECT * FROM WRI$_OPTSTAT_HISTGRM_HISTORY;→TRUNCATE原表 →INSERT /*+ APPEND */回迁，避免长事务和 UNDO 压力
关 ASTS（19.7+）：CDB/PDB 都得关，否则白清
WRI$_SQLSET_PLAN_LINES 在 19.7 默认启用，19.8+ 默认关闭；若你用的是 19.7，它极可能是 SYSAUX 爆满的元凶：
- 确认状态：
SELECT client_name, status FROM cdb_autotask_client WHERE client_name = 'sql tuning advisor';（注意 CDB 和每个 PDB 都要查） - 关闭命令必须在 CDB$ROOT 和所有 PDB 中分别执行：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'sql tuning advisor', operation => NULL, window_name => NULL); - 关完再清表：
TRUNCATE TABLE WRI$_SQLSET_PLAN_LINES;（不要DROP，它由 Oracle 内部管理） - 切记：只关 CDB 不关 PDB，PDB 里照样写，SYSAUX 会继续涨
真正难的不是执行哪条命令，而是判断哪个组件在“偷偷写”、是否跨容器生效、以及清理后有没有残留段没 shrink。比如 WRH$_ACTIVE_SESSION_HISTORY 分区截断后，若没配 ALTER TABLE ... SHRINK SPACE CASCADE，空间还是不会还给表空间。
