如何管理Oracle SYSTEM和SYSAUX表空间空间增长

作者：袖梨 2026-08-24

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_MBFROM dba_segmentsWHERE tablespace_name = 'SYSTEM'AND owner NOT IN ('SYS', 'SYSTEM', 'OUTLN', 'XDB')ORDER BY bytes DESC;
  1. 如果结果里出现业务用户（比如APP_USER），立刻迁移：ALTER TABLE app_user.orders MOVE TABLESPACE users;
  2. 索引同理：ALTER INDEX app_user.idx_order_id REBUILD TABLESPACE users;
  3. 千万别用TRUNCATE或DROP直接删——这些对象很可能还在用，删了会报ORA-00942或导致应用异常
  4. 迁移后，确认dba_segments里已清空，再检查dba_free_space是否释放出空间；没释放说明高水位没降，需后续SHRINK SPACE或重建

SYSAUX表空间持续增长，优先查占用大户组件

SYSAUX不是“垃圾桶”，它按组件（occupant）分类管理空间。先看谁在吃空间：

SELECT occupant_name, occupant_desc, space_usage_kbytes/1024 USAGE_MBFROM v$sysaux_occupantsORDER BY space_usage_kbytes DESC;

常见高占比项及对应动作：

  1. SM/OPTSTAT（统计信息历史）：查保留天数dbms_stats.get_stats_history_retention()，超8天就调低，如exec dbms_stats.alter_stats_history_retention(7);
  2. AWR（自动工作负载仓库）：查快照保留SELECT retention FROM dba_hist_wr_control;，若设得过大（如30天），用EXEC dbms_workload_repository.modify_snapshot_settings(retention => 86400);（单位秒）
  3. ASTS（Oracle 19.7新增的自动SQL调优集）：在CDB和所有PDB中都执行EXEC DBMS_AUTO_STS.DISABLE;，否则只在CDB禁用，PDB仍会写入
  4. 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_partitionsWHERE table_name = 'WRH$_ACTIVE_SESSION_HISTORY' AND ROWNUM

如果只看到SYS_P123这类系统生成名，且HIGH_VALUE全是MAXVALUE，说明没正常分区。这时要手动触发分裂：

  1. 先开调试会话：ALTER SESSION SET "_swrf_test_action" = 72;
  2. 该命令对所有AWR分区表生效，一次只分裂一个层级，需反复执行几次才能拆出可清理的小分区
  3. 分裂后，再跑DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE，就能真正删掉旧快照
  4. 切记：不要直接TRUNCATE WRH$_*表——这会破坏AWR完整性，DBA_HIST_*视图将无法查询

扩容只是临时止痛，监控必须跟上

加数据文件能解燃眉之急，但掩盖不了配置缺陷。SYSAUX超过5GB、SYSTEM超过1GB，就该触发告警。

日常必须固化两件事：

  1. 每月跑一次空间占用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;
  2. 把v$sysaux_occupants和dba_hist_wr_control纳入Zabbix或OEM监控项，阈值设为占用率>85%或保留天数>14天
  3. CDB环境特别注意：ALTER SYSTEM SET statistics_level = BASIC在PDB级别无效，必须在每个PDB里单独执行

最易被忽略的是PDB独立配置——CDB改了，PDB没动，SYSAUX照样涨。查PDB状态不能只连CDB$ROOT，得挨个ALTER SESSION SET CONTAINER = pdb1;再查。

相关文章

精彩推荐