ORA-00942错误源于AUD$表所在表空间不可用或未启用传统审计；AUDIT_FILE_DEST仅控制OS级审计文件路径，与表空间无关，统一审计使用AUDSYS表空间且默认启用。
ORA-00942 错误：审计表 AUD$ 不在默认表空间，但 AUDIT_FILE_DEST 已指向其他路径
oracle 19c 的审计行为分两类：语句级/权限级审计写入数据字典表 aud$（或统一审计视图 unified_audit_trail），而传统审计的审计文件（如 ora_12345.trc）才真正受 audit_file_dest 控制。很多人误以为改了 audit_file_dest 就能“把审计日志存到某个表空间”，其实它根本不管理表空间——只管操作系统目录。
常见错误现象：SELECT * FROM DBA_AUDIT_TRAIL 查不到记录，但 ls -l $ORACLE_BASE/admin/$ORACLE_SID/adump/ 下有大量 .aud 文件；或者启用了标准审计却没看到数据进 AUD$，是因为 AUD$ 所在的 SYSTEM 表空间满了或被只读锁定。
-
AUDIT_FILE_DEST是一个初始化参数，值必须是绝对路径（如/u01/app/oracle/admin/ORCL/adump），不能是 ASM 路径或相对路径 - 该路径需由 Oracle 进程用户（如
oracle）拥有写权限，且磁盘剩余空间建议 ≥5GB（否则审计可能静默失败） - 修改后需重启实例生效（
ALTER SYSTEM SET AUDIT_FILE_DEST='...' SCOPE=SPFILE仅更新 SPFILE，不热生效）
如何确认 AUD$ 表实际所在的表空间及是否可写
AUD$ 是传统审计的核心基表，位于 SYSTEM 表空间（19c 默认未迁移），它的位置和状态直接影响审计是否落库。统一审计（UNIFIED_AUDIT_TRAIL）则用 AUDSYS 表空间，二者物理隔离。
执行以下查询快速定位：
SELECT owner, table_name, tablespace_name, status FROM dba_tables WHERE table_name = 'AUD$';
若返回为空，说明你启用了统一审计（UNIFIED_AUDIT_TRAIL 生效），此时应查 AUDSYS 表空间：
SELECT tablespace_name, status, contents FROM dba_tablespaces WHERE tablespace_name = 'AUDSYS';
- 如果
AUD$所在表空间STATUS是READ ONLY或OFFLINE，审计插入会失败，但无明显报错——日志里只有ORA-01653类错误 -
AUDSYS表空间不可手动删、不可设为 read only，也不能用ALTER DATABASE DEFAULT TABLESPACE切换 - 检查
AUD$是否被移动过：SELECT segment_name, tablespace_name FROM dba_segments WHERE segment_name = 'AUD$'
统一审计下，AUDIT_FILE_DEST 还有用吗？
有用，但用途窄：它只控制 Oracle 自身后台进程（如 oraagent、osysmond）产生的诊断日志（.trc/.log），以及极少数未被统一审计覆盖的旧式操作（比如某些 RMAN 备份审计）。真正的 SQL 审计、权限变更、登录登出等，全走 UNIFIED_AUDIT_TRAIL，与 AUDIT_FILE_DEST 无关。
验证方式：启用统一审计后执行 AUDIT SELECT TABLE BY scott;，再用 scott 登录查表，然后查：
SELECT event_timestamp, action_name, object_name FROM unified_audit_trail WHERE action_name = 'SELECT' AND object_name IS NOT NULL;
你会发现结果存在，而 $AUDIT_FILE_DEST 目录下并无对应 .aud 文件。
- 统一审计默认开启，且无法关闭（19c+）；传统审计（
AUD$）仍可开，但两者并存时，优先走统一路径 -
AUDIT_FILE_DEST的值不影响UNIFIED_AUDIT_TRAIL的存储位置——那是AUDSYS表空间的事 - 若要导出统一审计记录，用
DBMS_AUDIT_MGMT包，不是靠拷贝文件
审计路径与表空间映射的实质关系
不存在直接映射。Oracle 审计机制里，“路径”和“表空间”属于两个平行轨道：AUDIT_FILE_DEST → OS 文件系统；AUD$ 或 AUDSYS → 数据库内部存储。强行让它们“对齐”，比如把 AUDIT_FILE_DEST 设成 /u01/oradata/audsys/ 并期望审计内容写进去，只会白忙活。
真正需要关注的是两件事：一是确保 AUDSYS 表空间有足够自动扩展能力（ALTER TABLESPACE AUDSYS ADD DATAFILE ... AUTOEXTEND ON），二是定期清理旧审计记录（DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL），否则表空间涨满后新审计就停摆。
-
AUDSYS表空间的数据文件路径，和AUDIT_FILE_DEST的路径可以完全不重合，也无需重合 - 不要尝试用
CREATE TABLESPACE ... LOCATION '<AUDIT_FILE_DEST>'，ASM 和非 ASM 环境都不支持这种绑定 - 最易忽略的一点：
AUDSYS表空间默认不显示在DBA_TABLESPACES的CONTENTS列中为UNDO或PERMANENT，而是AUDIT—— 这个类型不能被普通 DDL 操作
