system表空间暴涨主因是用户对象误建其中，需用select owner,segment_name...定位非sys用户对象并迁移至常规表空间；sysaux持续增长则优先查v$sysaux_occupants，针对awr、optstat、asts等组件调优保留策略或禁用功能。
SYSTEM表空间暴涨，先查是不是对象误建进去了
SYSTEM表空间只该存数据字典和系统对象，任何用户表、索引、LOB都不该出现在这里。一旦发现非SYS用户对象占了大量空间，基本就是应用或脚本没指定TABLESPACE参数，被默认塞进SYSTEM。
执行这条语句快速定位：
SELECT owner, segment_name, segment_type, bytes/1024/1024 SIZE_MB
FROM dba_segments
WHERE tablespace_name = 'SYSTEM'
AND owner NOT IN ('SYS', 'SYSTEM', 'OUTLN', 'XDB')
ORDER BY bytes DESC;
- 如果结果里出现业务用户（比如
APP_USER），立刻迁移：ALTER TABLE app_user.orders MOVE TABLESPACE users; - 索引同理：
ALTER INDEX app_user.idx_order_id REBUILD TABLESPACE users; - 千万别用
TRUNCATE或DROP直接删——这些对象很可能还在用，删了会报ORA-00942或导致应用异常 - 迁移后，确认
dba_segments里已清空，再检查dba_free_space是否释放出空间；没释放说明高水位没降，需后续SHRINK SPACE或重建
SYSAUX表空间持续增长，优先查占用大户组件
SYSAUX不是“垃圾桶”，它按组件（occupant）分类管理空间。先看谁在吃空间：
SELECT occupant_name, occupant_desc, space_usage_kbytes/1024 USAGE_MB FROM v$sysaux_occupants ORDER BY space_usage_kbytes DESC;
常见高占比项及对应动作：
-
SM/OPTSTAT（统计信息历史）：查保留天数dbms_stats.get_stats_history_retention()，超8天就调低，如exec dbms_stats.alter_stats_history_retention(7); -
AWR（自动工作负载仓库）：查快照保留SELECT retention FROM dba_hist_wr_control;，若设得过大（如30天），用EXEC dbms_workload_repository.modify_snapshot_settings(retention => 86400);（单位秒） -
ASTS（Oracle 19.7新增的自动SQL调优集）：在CDB和所有PDB中都执行EXEC DBMS_AUTO_STS.DISABLE;，否则只在CDB禁用，PDB仍会写入 -
ADVISOR（优化器建议任务）：禁用任务DBMS_ADVISOR.DELETE_TASK+ 清空底层表WRI$_ADV_OBJECTS等，注意TRUNCATE前先备份
查到大表但TRUNCATE失败？可能是分区卡住了
比如WRH$_ACTIVE_SESSION_HISTORY长期不清理，不是因为保留策略没生效，而是分区没分裂，导致整分区无法被DROP——哪怕只有1行未过期，整个GB级分区都留着。
验证方式：
SELECT partition_name, high_value FROM dba_tab_partitions WHERE table_name = 'WRH$_ACTIVE_SESSION_HISTORY' AND ROWNUM <p>如果只看到<code>SYS_P123</code>这类系统生成名，且<code>HIGH_VALUE</code>全是<code>MAXVALUE</code>，说明没正常分区。这时要手动触发分裂：</p>
- 先开调试会话：
ALTER SESSION SET "_swrf_test_action" = 72; - 该命令对所有AWR分区表生效，一次只分裂一个层级，需反复执行几次才能拆出可清理的小分区
- 分裂后，再跑
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE，就能真正删掉旧快照 - 切记：不要直接
TRUNCATE WRH$_*表——这会破坏AWR完整性，DBA_HIST_*视图将无法查询
扩容只是临时止痛，监控必须跟上
加数据文件能解燃眉之急，但掩盖不了配置缺陷。SYSAUX超过5GB、SYSTEM超过1GB，就该触发告警。
日常必须固化两件事：
- 每月跑一次空间占用TOP 10：
SELECT segment_name, owner, bytes/1024/1024 SIZE_MB FROM dba_segments WHERE tablespace_name IN ('SYSTEM','SYSAUX') ORDER BY bytes DESC FETCH FIRST 10 ROWS ONLY; - 把
v$sysaux_occupants和dba_hist_wr_control纳入Zabbix或OEM监控项，阈值设为占用率>85%或保留天数>14天 - CDB环境特别注意：
ALTER SYSTEM SET statistics_level = BASIC在PDB级别无效，必须在每个PDB里单独执行
最易被忽略的是PDB独立配置——CDB改了，PDB没动，SYSAUX照样涨。查PDB状态不能只连CDB$ROOT，得挨个ALTER SESSION SET CONTAINER = pdb1;再查。
