AUD$和AUDSYS均不支持跨表空间迁移，因二者均为受保护的数据字典对象；缓解空间压力应通过DBMS_AUDIT_MGMT清理、调整保留策略及禁用非必要审计策略实现。
不能把审计记录“导出到独立表空间”——aud$ 和 audsys 都不支持跨表空间迁移，强行操作会破坏数据字典一致性。
为什么 AUD$ 不能移到其他表空间
AUD$ 是传统审计的核心基表，Oracle 19c 默认将其固定在 SYSTEM 表空间，且不允许用 ALTER TABLE ... MOVE TABLESPACE 或导出导入方式迁移。原因包括：
- 它属于数据字典对象，受 Oracle 内部保护机制锁定，普通 DDL 会被拒绝（报
ORA-00942或ORA-30511） - 即使通过隐式手段（如 expdp + impdp 带 REMAP_TABLESPACE）强行导入，也会导致
DBA_AUDIT_TRAIL视图不可用、审计功能异常 - 官方明确禁止修改 AUD$ 所在表空间；19c 中也未提供迁移路径或补丁支持
统一审计下 AUDSYS 表空间也不能“导出”
如果你启用了统一审计（V$OPTION 中 Unified Auditing 返回 TRUE），审计记录实际写入 AUDSYS 表空间，但这个表空间有严格限制：
-
AUDSYS是只读、自动管理的系统表空间，不能执行ALTER TABLESPACE ... READ WRITE - 不能删除、重命名、移动其中任何段（如
UNIFIED_AUDIT_TRAIL对应的内部表） - 没有
EXPORT_AUDIT_TRAIL这类过程；DBMS_AUDIT_MGMT的导出功能仅适用于传统审计（AUD$）且需先启用 OS/XML 审计模式 - 所谓“导出”，只能是查询后用外部工具（如 SQL*Plus spool）生成文本，或用 Data Pump 导出视图结果集（非原始审计表）
真正可落地的减压方案：清理 + 切换审计模式
要缓解 SYSTEM 或 SYSAUX（含 AUDSYS）压力，必须放弃“导出到独立表空间”的思路，转为以下实操动作：
- 确认当前审计类型：
SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';—— 若为FALSE，说明用的是传统审计，AUD$在SYSTEM；若为TRUE，则AUDSYS在SYSAUX（或独立AUDSYS表空间） - 传统审计下，定期清理：
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB, USE_LAST_ARCH_TIMESTAMP => TRUE);，前提是已调用SET_LAST_ARCHIVE_TIMESTAMP - 统一审计下，清理 AUDSYS：
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, USE_LAST_ARCH_TIMESTAMP => TRUE);，同样依赖时间戳标记 - 如果
AUDSYS占用过大（查V$SYSAUX_OCCUPANTS确认），可缩短保留策略：EXEC DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, PROPERTY_NAME => 'MAX_LOG_SIZE', PROPERTY_VALUE => 104857600);（100MB） - 禁用非必要审计策略：
NOAUDIT POLICY xxx;，比清空更治本；避免对全库或高频率对象（如序列、字典视图）开启细粒度审计
最容易被忽略的关键点
所有清理操作都依赖 DBMS_AUDIT_MGMT.INIT_CLEANUP 是否已执行，且 USE_LAST_ARCH_TIMESTAMP 必须为 TRUE 才生效；否则 CLEAN_AUDIT_TRAIL 只是空跑，不删任何数据。另外，AUDSYS 表空间无法 shrink，它的空间释放是异步延迟的，清理后需等待数分钟再查 V$SYSAUX_OCCUPANTS 确认效果。
