ORA-02002在Oracle 19c RAC中多因SYSTEM表空间写满所致，根源常是SYS.AUD$仍位于SYSTEM；需先查dba_segments确认位置，再通过DBMS_AUDIT_MGMT迁移并ALTER TABLE MOVE至非SYSTEM表空间，RAC下须所有实例MOUNT状态执行。
ORA-02002报错时别只盯着audit_trail参数
看到ora-02002: error while writing to audit trail，第一反应常是去查audit_file_dest或关掉audit_trail。但在oracle 19c rac中，这个错误大概率是system表空间写满的“替罪羊”，尤其当审计功能实际走的是统一审计（audsys）且默认仍把部分旧式审计对象（如sys.aud$）留在system里时。rac环境下多个实例并发写入，放大了空间争用风险。此时修改参数不解决根本问题，反而可能掩盖真实瓶颈。
确认AUD$是否真在SYSTEM表空间里
19c虽主推统一审计，但兼容模式下仍可能残留传统审计表。必须先验证对象位置，不能凭经验假设：
- 执行
SELECT owner, segment_name, tablespace_name FROM dba_segments WHERE segment_name = 'AUD$' AND owner = 'SYS';—— 如果tablespace_name返回SYSTEM，就是它了 - 注意：不要直接查
dba_tables，AUD$是特殊基表，dba_segments才反映真实物理位置 - RAC中需在所有节点执行该查询，避免只查一个实例导致误判
迁移SYS.AUD$到非SYSTEM表空间的实操步骤
迁移比清空更安全，保留审计历史且不影响RAC集群一致性：
- 确保目标表空间（如
USERS或新建的AUDIT_TBS）已存在、在线、且有足够空闲空间：SELECT tablespace_name, status, contents FROM dba_tablespaces WHERE tablespace_name IN ('USERS', 'AUDIT_TBS'); - 用
DBMS_AUDIT_MGMT包迁移前，先停用传统审计：NOAUDIT ALL;（避免迁移中写入冲突） - 执行迁移：
EXEC DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, property_name => DBMS_AUDIT_MGMT.DB_DEFAULT_TABLESPACE, property_value => 'USERS'); - 迁移生效需重启数据库？不需要。但需手动移动现有数据：
ALTER TABLE SYS.AUD$ MOVE TABLESPACE USERS;—— 这步在RAC中必须在所有实例都处于MOUNT状态时执行（即停库），否则报ORA-01157 - 迁移后重建索引：
ALTER INDEX SYS.I_AUD1 REBUILD TABLESPACE USERS;
RAC环境特别要注意的坑
在RAC中操作SYS.AUD$，稍有不慎就会触发节点间锁等待或静默失败：
-
ALTER TABLE ... MOVE不是在线操作，必须所有实例停库（SHUTDOWN IMMEDIATE+STARTUP MOUNT），单节点执行会卡住其他节点 - 迁移后检查各节点alert.log，确认无
ORA-00604递归SQL错误——这说明某节点仍试图往旧位置写 - 统一审计（
AUDSYS）默认在SYSAUX，和SYSTEM无关，但若你同时启用了传统审计+统一审计，两个通道的数据会并存，需分别清理或归档 - 迁移完成后，立刻禁用传统审计：
ALTER SYSTEM SET audit_trail=NONE SCOPE=SPFILE;，再重启，彻底切断SYSTEM表空间的审计写入路径
SYS.AUD$的任何DDL操作都要求全局一致状态。没协调好所有节点就动手，轻则迁移失败，重则某个实例hang住无法拉起。
