适用于:

用途

当系统中的审计功能被启用时，审计记录的数量将对升级性能产生负面的影响。

解决这个问题有2个传统的方法：
1: 允许升级进程使用足够的时间来处理这些记录（可能需要花费几个小时，取决于记录的数量）
2: 在升级前Truncate审计表。这个选择会导致历史安全数据的丢失。
     尽管这从不是一个推荐的方案，但是由于停机窗口时间的限制，有时必须这样处理。 
      在考虑这个方案前，用户需要与其安全管理员审核，如果采用，用户需要自担风险。

现在一个新的方法和脚本允许用户预处理这些审计记录。这篇文档为用户提供了预处理审计记录的方法和脚本，减少了升级过程中这个步骤所需要的时间。

适用范围

这个方法对于从10.1或更高版本升级到11.1或更高版本的数据库有效（包括标准版和专业版）。

当下面任一个表的审计记录条数庞大（超过250,000），这个脚本就需要被考虑：
sys.aud$             这个方法不适用于升级前为9.2的数据库。
在9.2中为了避免deadlock的产生，在做预处理时实例状态必须是upgrade / restricted，这与预处理的目的背道而驰。

这个方法不适用于实际升级过程中产生的与审计记录相关的问题。

详细信息

步骤:
1: 查看审计表中的行数
    标准审计
               SELECT count(*) FROM sys.aud$ WHERE dbid is null;
    标准审计，只有当Oracle Label Security (OLS) 和/或 Database Vault (DV)被安装时
               SELECT count(*) FROM system.aud$ WHERE dbid is null;
    Fine Grained Auditing
               SELECT count(*) FROM sys.fga_log$ WHERE dbid is null;

2: 如果审计记录条数庞大（例如：超过250,000），考虑预处理审计记录。

通过预处理，那些在升级过程中需要做的改变可以在升级前完成，同时保证实例为正常运行状态。根据需要处理的记录数量和新生成的审计记录数量，脚本需要一段比较长的时间来完成，而且可能需要在升级前被执行多次。

通常我们推荐在升级前的一周内执行此脚本，之后观察审计记录条数的变化。

如果执行这个脚本带来了性能的问题，它可以在执行的过程中使用ctrl-c来停止，并在另一个空闲时间重新开始。

我们推荐在做预处理审计记录前，检查数据库sys / system是否有无效对象，并使用utlrp.sql脚本来解决。如果utlrp脚本无法使对象有效，您可以创建SR寻求Oracle Support的帮助。

下面文档中包含有用的脚本，可以在升级前检查数据库：
NOTE:556610.1 - Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
NOTE:884522.1 - How to Download and Run Oracle's Database Pre-Upgrade Utility

或者

如果你不能预处理SYS.AUD$, 那么可以采取下面的步骤

绕过的方法:

1) 导出SYS.AUD$表

2) Truncate SYS.AUD$ 表

3) 升级数据库

4) 在数据库升级完成后,再导入SYS.AUD$表

 关于更具体的步骤,请参考文档 Note 73408.1 :  How to Truncate, Delete, or Purge Rows from the Audit Trail Table AUD$  

参考