统一审计在RAC中必须先通过每个节点执行make -f ins_rdbms.mk uniaud_on ioracle并重启所有实例启用，否则DBMS_AUDIT_MGMT调用会报ORA-46269错误；启用后该包才可用于清理、迁移等运维操作。
统一审计在 rac 中无法仅靠 dbms_audit_mgmt 启用——它必须先通过 relink 操作激活，否则调用该包会报错或静默失败。
统一审计启用和 DBMS_AUDIT_MGMT 的关系
很多人误以为执行 DBMS_AUDIT_MGMT.INIT_CLEANUP 或 SET_AUDIT_TRAIL_LOCATION 就算启用了统一审计，其实不是。这些包函数只在统一审计已启用的前提下才有效；如果 v$option 中 Unified Auditing 返回 FALSE，所有 DBMS_AUDIT_MGMT 调用都会失败（常见报错：ORA-46269: Unified auditing is not enabled）。
真正启用的门槛是操作系统级的 relink：必须在每个 RAC 节点上运行 make -f ins_rdbms.mk uniaud_on ioracle，然后重启所有实例。这是不可跳过的前置步骤。
RAC 环境中 DBMS_AUDIT_MGMT 的典型使用场景
启用统一审计后，DBMS_AUDIT_MGMT 才开始承担实际管理职责，比如清理、归档、迁移路径。它不参与“开关”逻辑，只负责后续运维。
-
INIT_CLEANUP必须在首次启用后立即执行一次，否则无法设置清理策略 -
SET_AUDIT_TRAIL_LOCATION用于迁移AUDSYS表空间位置（如从本地文件系统切到 ASM），但需配合重启所有实例才生效 -
CLEAN_AUDIT_TRAIL清理时注意：若未先调用FLUSH_UNIFIED_AUDIT_TRAIL，可能漏删 SGA 中缓存的记录 -
FLUSH_UNIFIED_AUDIT_TRAIL是强制刷写内存中未落盘审计记录的关键操作，尤其在高并发 DML 后手动触发更可靠
容易踩的坑：RAC 多节点一致性被忽略
RAC 下 DBMS_AUDIT_MGMT 的行为天然跨实例，但前提是所有节点都已完成 relink 并重启。常见错误包括：
- 只在一个节点执行 relink，其他节点仍为
FALSE→ 查询unified_audit_trail时部分节点无数据 - 迁移
AUDSYS到 ACFS 后，未在所有节点验证挂载状态（acfsutil info fs）→ 某些实例启动失败或审计写入静默丢弃 - 调用
CLEAN_AUDIT_TRAIL时未指定use_last_arch_timestamp => FALSE→ 默认只清归档时间戳之后的数据，历史记录残留 - 误改
audit_file_dest参数 → 对统一审计完全无效，纯属干扰项
最常被忽略的一点：relink 后必须重启所有 RAC 实例，而不仅仅是数据库服务（srvctl stop/start database 不够，还需确保 CRS 资源状态同步）。否则 v$option 可能显示 TRUE，但实际审计记录仍不生成。
