Skip Headers
Oracle® Audit Vault Administrator's Guide
Release 10.2.3

Part Number E11059-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Administrative Tasks

This chapter describes important administrative tasks to perform on the Audit Vault system. These tasks are especially important if your audit data collectors are collecting high volumes of audit records and rapidly filling default tablespace and disk space settings.

The Audit Vault system Administrator should perform the following administrative tasks on a running Audit Vault system:

4.1 Monitoring Space Usage on the SYSAUX Tablespace

Following an Audit Vault Server installation and the creation of the Audit Vault database, the SYSAUX tablespace is created by default with one data file. The SYSAUX tablespace is a locally managed tablespace with automatic segment space management.

The Audit Vault administrator should monitor the space usage for the SYSAUX tablespace and set up additional datafiles for storage as needed. See Oracle Database Administrator's Guide for more information about the SQL ALTER TABLESPACE command.

4.2 Monitoring Disk Space Usage Where Archive Logs Are Stored

During an Audit Vault Server installation, ARCHIVELOG mode is turned on by default. For this reason, the Audit Vault administrator must monitor the disk space usage for these files to prevent a small disk from quickly filling to capacity. See Oracle Database Administrator's Guide for more information about changing the LOG_ARCHIVE_DEST_n location to relocate these archive log files to larger disks. For information about backing up the archive logs, see Oracle Database Backup and Recovery Advanced User's Guide.

4.3 Monitoring the Flash Recovery Area

Following an Audit Vault Server installation, the DB_RECOVERY_FILE_DEST_SIZE initialization parameter is set to 2G and the DB_RECOVERY_FILE_DEST initialization parameter is set to the default flash recovery area, typically the ORACLE_HOME>/flash_recovery_area directory. The size of the flash recovery area should be large enough to hold a copy of all data files, all incremental backups, online redo logs, archived redo log not yet backed up on tape, control files, and control file auto backups. Depending upon how many collectors are configured, the scope of audit record collection being administered, and the backup and archive plans in operation, this space can fill to capacity rather quickly.

Use Oracle Enterprise Manager DB Console to monitor the available space in the flash recovery area. Monitor the percent space that is useable in the Usable Flash Recovery Area field under the High Availability section on the Home page. Check the alert log in the DB Console for messages. When the used space in the flash recovery area reaches 85%, a warning message is sent to the alert log. When the used space in the flash recovery area reaches 97%, a critical warning message is sent to the alert log.

The Audit Vault administrator can manage space in the flash recovery area by adjusting the retention policy for data files to keep fewer copies or reduce the number of days these files stay in the recovery window. Another alternative is to increase the value of the DB_RECOVERY_FILE_DEST_SIZE initialization parameter to accommodate these files and to set the DB_RECOVERY_FILE_DEST initialization parameter to a value where more disk space is available. See Oracle Database Administrator's Guide and Oracle Database Backup and Recovery Basics for more information.

4.4 Setting Up Oracle Database Sources for Managing Audit Trail Records

This section describes audit trail management using the DBMS_AUDIT_MGMT package that is supported in source databases from which you can collect audit records. This new source database functionality is available as a patchset. Please check OracleMetaLink and the Oracle Audit Vault Release Notes on the specific versions that are supported.

The OracleMetaLink Web site is available at

https://metalink.oracle.com

If you do not have a current Oracle Support Services contract, then you can access the same information at

http://www.oracle.com/technology/support/metalink/content.html

This section contains:

4.4.1 Automatically Managing Audit Trail Records on the Oracle Source Database

A new package called DBMS_MGMT_AUDIT provides the infrastructure to integrate the source database with Audit Vault to automatically delete audit trail records once they are inserted into Audit Vault. In addition, the new DBMS_MGMT_AUDIT package also provides additional procedures to move the source database audit trail tables (sys.aud$, sys.fga_log$) out of the system tablespace and purge the audit trail records or files.

This section contains:

4.4.1.1 Moving the Database Audit Trail to a Different Tablespace

By default, the SYSTEM tablespace stores the database audit trail AUD$ and FGA_LOG$ tables. You can change this default location to another tablespace, such as the SYSAUX tablespace or a user-created tablespace. You may want to move the database audit trail tables to a different tablespace if the SYSTEM tablespace is too busy.

Be aware that moving the database audit trail tables to a different tablespace can take a while, so you may want to do this during a time when database activity is slow.

To move the database audit trail from SYSTEM to a different tablespace:

  1. Log in to SQL*Plus as an administrator who has the EXECUTE privilege on the DBMS_AUDIT_MGMT PL/SQL package.

    For more information about the DBMS_AUDIT_MGMT PL/SQL package, see Appendix G.

  2. Check the tablespace to which you want to move the database audit trail tables.

    You may need to optimize and allocate more space to this tablespace, including the SYSAUX auxiliary tablespace. For more information, see Oracle Database Performance Tuning Guide.

  3. Run the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION PL/SQL procedure to specify the name of the destination tablespace and move it to that tablespace.

    For example:

    BEGIN
     DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
      AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, 
      AUDIT_TRAIL_LOCATION_VALUE  => 'AUD_AUX');
    END;
    

    In this specification:

    • AUDIT_TRAIL_TYPE: Refers to the database audit trail type. Enter one of the following values:

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard audit trail table, AUD$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables.

    • AUDIT_TRAIL_LOCATION_VALUE: Specifies the destination tablespace. This example specifies a tablespace named AUD_AUX.

4.4.2 Purging Audit Trail Records

This section contains:

See Also:

Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_AUDIT_MGMT PL/SQL package, which you use to perform most of the tasks described in this section

Note:

  • Oracle Database audits all deletions from the audit trail, without exception.

  • The purge process may generate additional redo logs.

4.4.2.1 Automatically Purging Audit Trail Records

This section contains:

4.4.2.1.1 Setting Up an Automatic Purge Job for the Audit Trail

The automatic purge job deletes all audit records that were created before the last recorded timestamp. Be aware that purging the audit trail, particularly a large one, can take awhile to complete. Consider scheduling the purge job so that it runs during a time when the database is not busy.

To set up an automatic purge job:

Step 1: Initialize the Audit Trail Clean-Up Operation

Before you can purge the audit trail, you must initialize the audit trail clean-up operation. For the database audit trail, if you have not moved the database audit trail tables (SYS.AUD$ and SYS.FGA_LOG$) from the SYSTEM tablespace to another tablespace, this process moves these tables to the SYSAUX tablespace, or the tablespace that is specified in the SET_TABLESPACE procedure. Be aware that moving these tables takes a while, so you may want to schedule the initialization process during time when the database is not busy.

To initialize the audit trail clean-up operation:

  1. Log in to SQL*Plus as an administrative user who has the EXECUTE privilege on the DBMS_AUDIT_MGMT PL/SQL package.

  2. Initialize the audit trail clean-up operation by running the DBMS_AUDIT_MGMT.INIT_CLEANUP procedure.

    For example:

    BEGIN
     DBMS_AUDIT_MGMT.INIT_CLEANUP(
      AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD,
      DEFAULT_CLEANUP_INTERVAL    => 12 );
    END
    

    In this specification:

    • AUDIT_TRAIL_TYPE: Enter one of the following values:

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD: Standard audit trail table, AUD$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML Operating system audit trail files.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: All audit trail records, that is, both database audit trail and operating system audit trail types.

    • DEFAULT_CLEANUP_INTERVAL: Specify the desired default hourly purge interval, for example, 12.

Step 2: Create the Purge Job

Create the purge job by running the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB PL/SQL procedure.

For example:

BEGIN
  DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
   AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD, 
   AUDIT_TRAIL_PURGE_INTERVAL  => 12,
   AUDIT_TRAIL_PURGE_NAME      => 'Standard_Audit_Trail_PJ',
   USE_LAST_ARCH_TIMESTAMP     => TRUE );
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Enter one of the following values:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD: Standard audit trail table, AUD$

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML audit trail files

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: All audit trail records, that is, both database audit trail and operating system audit trail types

  • AUDIT_TRAIL_PURGE_INTERVAL: Specify the hourly interval for this purge job to run. The timing begins when you run the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB procedure, in this case, 12 hours after you run the procedure. Later on, if you want to update this value, run the DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL procedure.

  • USE_LAST_ARCH_TIMESTAMP: Enter either of the following settings:

    • TRUE: Deletes audit records created before the last archive timestamp. To check the last recorded timestamp, query the DBA_AUDIT_MGMT_LAST_ARCH_TS data dictionary view. The default value is TRUE.

    • FALSE: Deletes all audit records without considering last archive timestamp.

Step 3: (Optional) Setting the Parameter to Delete Database Audit Trail Records in Batches

By default, the DBMS_AUDIT_MGMT package procedures delete the database audit trail records in batches of 10,000 records. You can set this batch size to a different value if you want. Later on, when Oracle Database runs the purge job, it deletes each batch, rather than one record after another. To find the current batch size setting, query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view. See Section 4.4.2.3 for more information.

4.4.2.1.2 Verifying That the Audit Trail Is Initialized for Clean-Up

You can check if the audit trail has been initialized for clean-up by running the DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED function. If the audit trail has been initialized, then this function returns TRUE. If it is not, it returns FALSE.

For example:

SET SERVEROUTPUT ON
BEGIN
 IF 
   DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD)
 THEN
   DBMS_OUTPUT.PUT_LINE('AUD$ is initialized for clean-up');
 ELSE
   DBMS_OUTPUT.PUT_LINE('AUD$ is not initialized for clean-up.');
 END IF;
END;

In this specification:

4.4.2.1.3 Cancelling the Initialization Clean-Up Settings

You can cancel the DBMS_AUDIT_MGMT.INIT_CLEANUP settings, that is, the default clean-up interval, by invoking the DBMS_AUDIT_MGMT.DEINIT_CLEANUP procedure.

For example, to cancel all purge settings for the standard audit trail:

BEGIN
 DBMS_AUDIT_MGMT.DEINIT_CLEANUP(
  AUDIT_TRAIL_TYPE  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD);
END;

In this specification:

4.4.2.2 Manually Purging the Audit Trail

If you wish to manually purge the audit trail records from the source database, you can use the CLEAN_AUDIT_TRAIL procedure. As a best practice, you should set the USE_LAST_ARCH_TIMESTAMP to TRUE to ensure the audit trail record has been successfully inserted into Audit Vault or your archive location.

To manually purge the audit trail:

  1. Follow these steps under Section 4.4.2.1.1:

  2. Purge the audit trail records by running the DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQL procedure.

    For example:

    BEGIN
      DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
       AUDIT_TRAIL_TYPE           =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD,
       USE_LAST_ARCH_TIMESTAMP    =>  TRUE );
    END;
    

    In this specification:

    • AUDIT_TRAIL_TYPE: Enter one of the following values:

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD: Standard audit trail table, AUD$

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML audit trail files

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: All audit trail records, that is, both database audit trail and operating system audit trail types

      You can run multiple purge operations for different audit trail types, so long as they do not conflict. For example, you can purge the standard audit trail table and then the fine-grained audit trail table. However, you cannot then purge both or all types, that is, by using the DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD or DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL property.

    • USE_LAST_ARCH_TIMESTAMP: Enter either of the following settings:

      • TRUE: Deletes audit records created before the last archive timestamp. To find the value of the last recorded timestamp, query the DBA_AUDIT_MGMT_LAST_ARCH_TS data dictionary view.

      • FALSE: Deletes all audit records without considering last archive timestamp.

4.4.2.3 Setting a Records Batch Size for Database Audit Trail Purge Operations

This section contains:

4.4.2.3.1 Setting the Database Audit Trail Records Batch Size

When Oracle Database purges records from the database audit trail, it deletes them in batched groups at a time during the clean-up process. You can set the number of records that best suits your environment. If the database audit trail is very large (and audit trails can grow quite large), deleting the records in groups facilitates the purge operation.

For example:

BEGIN
 DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
  AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
  AUDIT_TRAIL_PROPERTY        => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE,
  AUDIT_TRAIL_PROPERTY_VALUE  => 100000);
END

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the audit trail type, which in this case is the database system audit trail. Enter one of the following values:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD: Standard audit trail table, AUD$.

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$.

  • AUDIT_TRAIL_PROPERTY: Uses the DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE property to indicate the batch size setting. To find the status of the current property settings, query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view.

  • AUDIT_TRAIL_PROPERTY_VALUE: Sets the number of audit records to be 1,000,000 for each batch. Enter a value between 100 and 1000000. To determine this number, consider the total number of records being purged, and the time interval in which the purge operation is performed. The default is 10000.

4.4.2.3.2 Clearing the Database Audit Trail Records Batch Size

To clear this setting, use the DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY procedure.

For example:

BEGIN
  DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
   AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE,
   USE_DEFAULT_VALUES      =>  TRUE );
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the audit trail type, which in this case is the database system audit trail. Enter one of the AUDIT_TRAIL_TYPE values listed in Section 4.4.2.3.1.

  • AUDIT_TRAIL_PROPERTY: Specifies the DB_DELETE_BATCH_SIZE property. Query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view to find the current status of this property.

  • USE_DEFAULT_VALUES: Enter one of the following values:

    • TRUE: Clears the current audit record batch size and uses the default value, 10000, instead.

    • FALSE: Oracle Database does not set any batch size for audit records. The default setting is FALSE.

4.4.2.4 Managing Audit Trail Purge Jobs

This section contains:

4.4.2.4.1 Enabling or Disabling an Audit Trail Purge Job

To enable or disable an audit trail purge job, use the DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS PL/SQL procedure.

For example:

BEGIN
 DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS(
  AUDIT_TRAIL_PURGE_NAME      => 'OS_Audit_Trail_PJ',
  AUDIT_TRAIL_STATUS_VALUE    => DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE);
END

In this specification:

  • AUDIT_TRAIL_PURGE_NAME: Specifies a purge job called OS_Audit_Trail_PJ. To find existing purge jobs, query the DBA_AUDIT_MGMT_CLEANUP_JOBS data dictionary view.

  • AUDIT_TRAIL_STATUS_VALUE: Enter one of the following properties:

    • DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE: Enables the specified purge job.

    • DBMS_AUDIT_MGMT.PURGE_JOB_DISABLE: Disables the specified purge job.

4.4.2.4.2 Setting the Default Audit Trail Purge Interval for Any Audit Trail Type

You can set a default purge operation interval, in hours, that must pass before the next purge operation takes place for a specified audit trail type.

For example:

BEGIN
 DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
  AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
  AUDIT_TRAIL_PROPERTY        => DBMS_AUDIT_MGMT.CLEAN_UP_INTERVAL,
  AUDIT_TRAIL_PROPERTY_VALUE  => 24);
END

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the audit trail type, which in this case is the database system audit trail. Choose from the following settings:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD: Standard audit trail table, AUD$

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML Operating system audit trail files

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: All audit trail records, that is, both database audit trail and operating system audit trail types

    You can set a default interval for multiple audit trail types, so long as they do not conflict. For example, you can set individual intervals for the DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_AUD and DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD properties, but not for the DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD property.

  • AUDIT_TRAIL_PROPERTY: Sets the DBMS_AUDIT_MGMT.CLEAN_UP_INTERVAL property to indicate the purge operation interval setting. To find the current property settings, query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view. The timing begins when you set the DBMS_AUDIT_MGMT.CLEAN_UP_INTERVAL property.

  • AUDIT_TRAIL_PROPERTY_VALUE: Updates the default hourly interval set by the DBMS_AUDIT_MGMT.INIT_CLEANUP procedure. Enter a value between 1 and 999.

4.4.2.4.3 Setting the Default Audit Trail Purge Job Interval for a Specified Purge Job

You can set a default purge operation interval, in hours, that must pass before the next purge job operation takes place. The interval setting that is used in the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB procedure takes precedence over this setting.

For example:

BEGIN
 DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL(
  AUDIT_TRAIL_PURGE_NAME       => 'OS_Audit_Trail_PJ',
  AUDIT_TRAIL_INTERVAL_VALUE   => 24 );
END

In this specification:

  • AUDIT_TRAIL_PURGE_NAME: Specifies the name of the audit trail purge job. To find a list of existing purge jobs, query the DBA_AUDIT_MGMT_CLEANUP_JOBS data dictionary view.

  • AUDIT_TRAIL_INTERVAL_VALUE: Updates the default hourly interval set by the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB procedure. Enter a value between 1 and 999. The timing begins when you run the purge job.

4.4.2.4.4 Deleting an Audit Trail Purge Job

To delete an audit trail purge job, use the DBMS_AUDIT_MGMT.DROP_PURGE_JOB PL/SQL procedure. To find existing purge jobs, you can query the DBA_AUDIT_MGMT_CLEANUP_JOBS data dictionary view.

For example:

BEGIN
 DBMS_AUDIT_MGMT.DROP_PURGE_JOB(
  AUDIT_TRAIL_PURGE_NAME  => 'FGA_Audit_Trail_PJ');
END

In this specification:

  • AUDIT_TRAIL_PURGE_NAME: Specifies a purge job called FGA_Audit_Trail_PJ.

4.4.2.5 Configuring Tracing Debug Levels for Purge Operations

To diagnose errors, you can set the trace level for purge operations. Oracle Database creates trace files in the location set by the USER_DUMP_DEST initialization parameter. To find this location, log in to SQL*Plus and enter SHOW PARAMETER USER_DUMP_DEST.

As an example of the type of error the trace debug levels can catch, suppose you try to move the database audit trail table from SYSTEM to a different tablespace. Before moving the tables to the new tablespace, Oracle Database checks the space of the destination tablespace to ensure that it can hold the database audit trail tables. The debug log level can reveal if there is not enough space.

Use the DBMS_AUDIT_MGMT.SET_DEBUG_LEVEL PL/SQL procedure to set the trace level.

For example:

BEGIN
DBMS_AUDIT_MGMT.SET_DEBUG_LEVEL(
 DEBUG_LEVEL   => TRACE_LEVEL_DEBUG);
END

In this specification:

  • DEBUG_LEVEL: Specify one of the following values:

    • TRACE_LEVEL_DEBUG

    • TRACE_LEVEL_ERROR (default setting)

4.4.3 Setting the Size of the Operating System Audit Trail

To control the size of the operating system audit trail, set the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property by using the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQL procedure. Remember that you must have the EXECUTE privilege for the DBMS_AUDIT_MGMT PL/SQL package before you can use it. When the operating system file meets the size limitation you set, Oracle Database stops adding records to the current file and then creates a new operating system file for the subsequent records.

If you set both the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE and the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE (described in Section 4.4.3) properties, then Oracle Database performs the action based the property value limit that is met first.

For example:

BEGIN
  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE            =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY        =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
   AUDIT_TRAIL_PROPERTY_VALUE  =>  102400);
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the operating system audit trail. Enter one of the following values:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML audit trail files.

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files.

  • AUDIT_TRAIL_PROPERTY: Specifies the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property to set the maximum size. To find the status of the current property settings, query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view.

  • AUDIT_TRAIL_PROPERTY_VALUE: Sets the maximum size to 102400 kilobytes. The default setting is 10,000 kilobytes (approximately 10 megabytes). Do not exceed 2 gigabytes.

Clearing the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE Setting

To clear the maximum file size setting, use the DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY procedure.

For example:

BEGIN
  DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
   USE_DEFAULT_VALUES      =>  TRUE );
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the operating system audit trail. Enter one of the AUDIT_TRAIL_TYPE values described in Section 4.4.3.

  • AUDIT_TRAIL_PROPERTY: Specifies the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property. You can query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view to find the current status of this property.

  • USE_DEFAULT_VALUES: Enter one of the following values:

    • TRUE: Clears the current value and uses the default value, 10,000 kilobytes, instead.

    • FALSE: Oracle Database does not use a default maximum size for the operating system or XML file growth. The files will continue to grow without limitation unless you configure the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE property. The default setting is FALSE.

4.4.4 Setting the Age of the Operating System Audit Trail

To control the age of the operating system audit trail, use the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQL procedure. Remember that you must have the EXECUTE privilege for the DBMS_AUDIT_MGMT PL/SQL package before you can use it. When the operating system file meets the age limitation you set, Oracle Database stops adding records to the current file and then creates a new operating system file for the subsequent records. For more information about the DBMS_AUDIT_MGMT PL/SQL package, see Oracle Database PL/SQL Packages and Types Reference.

If you set both the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE and the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE (described in Section 4.4.3) properties, then Oracle Database performs the action based on the property value limit that is met first.

For example:

BEGIN
  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE            =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY        =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
   AUDIT_TRAIL_PROPERTY_VALUE  =>  10 );
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies the operating system audit trail. Enter one of the following values:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries.)

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML audit trail files.

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files.

  • AUDIT_TRAIL_PROPERTY: Specifies the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE property to set the maximum age. To find the status of the current property setting, query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view.

  • AUDIT_TRAIL_PROPERTY_VALUE: Sets the maximum age to 10 days. Enter a value between 1 and 495. The default age is 5 days.

Clearing the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE Setting

To clear the maximum file age setting, use the DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY procedure.

For example:

BEGIN
  DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
   USE_DEFAULT_VALUES      =>  TRUE );
END;

In this specification:

  • AUDIT_TRAIL_TYPE: Specifies operating system audit trail. Enter one of the AUDIT_TRAIL_TYPE values listed in Section 4.4.3.

  • AUDIT_TRAIL_PROPERTY: Specifies the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE property. Query the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view to find the current status of this property.

  • USE_DEFAULT_VALUES: Specify one of the following values:

    • TRUE: Clears the current value and uses the default value, 5 days, instead.

    • FALSE: Oracle Database does not use a default maximum age for the operating system or XML file growth. In this case, the files will continue to age without limitation unless you configure the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property. The default setting is FALSE.

4.5 Setting Up a Collection Agent Listener to Listen to Other Nodes in an Oracle RAC Environment

In an Oracle Real Application Clusters (Oracle RAC) environment, after the Audit Vault Collection Agent is set up, the node on which the collection agent was installed has its listener set up to listen to only that node. Thus, only that node can be specified to which to connect. However, the administrator can set up the listener to listen to the other nodes.

For the OSAUD and DBAUD collectors, the Administrator must update the tnsnames.ora file during installation of the Audit Vault Collection Agents.

After the collection agent is set up, the tnsnames.ora file located in $ORACLE_HOME/network/admin might have the following alias:

AV = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node01)
(PORT = 1521))(CONNECT_DATA = (SERVICE_NAME = av.us.oracle.com))) 

For high availability, the administrator might need to edit the Audit Vault Collection Agent home tnsnames.ora file after the collection agent is set up and add the host and port of the other listeners. For example:

AV = 
  (DESCRIPTION = 
    (ADDRESS = (PROTOCOL = TCP)(HOST = node01)(PORT = 1521)) 
    (ADDRESS = (PROTOCOL = TCP)(HOST = node02)(PORT = 1521)) 
    (ADDRESS = (PROTOCOL = TCP)(HOST = node03)(PORT = 1521)) 
    (ADDRESS = (PROTOCOL = TCP)(HOST = node04)(PORT = 1521)) 
    (LOAD_BALANCE = yes) 
    (CONNECT_DATA = 
      (SERVER = DEDICATED) 
        (SERVICE_NAME = av.us.oracle.com) 
    ) 
  ) 

For the REDO collector, the administrator must log in as the srcuser at the source database and re-create the database link for av.us.oracle.com. The new database link can either have a list of host and port numbers or point to a tnsnames entry with the list of host and port numbers.

4.6 Making Connectivity to the Source from the Audit Vault Collection Agent More Highly Available in an Oracle RAC Environment

When a source is added to Oracle Audit Vault, the Audit Vault administrator must provide the host:port:service information for the source being added. This information is used for the following tasks from the collection agent:

Typically, when the Oracle Database instance on the host goes down or if the host machine goes down, the connectivity to the source from the Audit Vault Collection Agent is broken and any attempt to perform these tasks is unsuccessful because this connection is not available:

The Audit Vault administrator can do any or all of the following operations to make the connection between the source and the Audit Vault Collection Agent more highly available:

4.7 Changing Audit Vault User Passwords on a Regular Basis

Most businesses and groups adhere to some internal policy for changing user name passwords. This is usually part of a password management policy. This policy often requires users to make password changes on a regular basis, such as every 120 days. Changing Audit Vault user name passwords should be considered part of the same password management policy. This section provides additional information about Audit Vault user names and source user names and how and where password changes are implemented.

Table 4-1 shows where the passwords for the Audit Vault user names and source user names are stored and where password changes must be made. Note that if a password for a source user name is updated in the source database, then the password, because it is also stored in the wallet in the Audit Vault Collection Agent home, must also be updated.

Table 4-1 Where Passwords for the Audit Vault User Names and Source User Names Are Stored

Audit Vault Role Audit Vault User Name Is Password Stored in Wallet? How Is Password Change Made?

AV_ADMIN

avadminusr

Yes

Use the AVCA create_credential command to change the password in the wallet in the Audit Vault Server home. You must also change the password of this user in the database.

AV_AGENT

avagentusr

Yes

Use the AVCA create_credential command to change the password in the wallet in the Audit Vault Collection Agent home. You must also change the password of this user in the database.

Source user on source database

srcusr

Yes

Use the SQL ALTER USER command on the source database Audit Vault Server home.

Use the AVORCLDB setup command or the AVMSSQLDB setup command to change the password in the wallet in the Audit Vault Collection Agent home

AV_AUDITOR

avauditorusr

No

Use the SQL ALTER USER command in the Audit Vault Server home


Change the Passwords of the avauditorusr User Name in the Audit Vault Server Home

To change the passwords of the avauditorusr user name, make the change in the Audit Vault Server home in the Audit Vault database using the SQL ALTER_USER command. Log in as the user with the role of Database Vault Account Manager.

For example, to change passwords of the avauditorusr user name, perform the following steps:

  1. Log in to SQL*Plus as the Database Vault Account Manager.

    For the Basic installation, log in as follows:

    sqlplus /nolog 
    SQL> connect avadmindva
    Enter password: avadmin-user-password
    Connected.
    SQL>
    

    For the Advanced installation, log in as follows:

    sqlplus /nolog
    SQL> connect dv_acctmgr-user-name
    Enter password: dv_acctmgr-user-password
    Connected.
    SQL>
    
  2. To change the avauditorusr name password, use the SQL ALTER USER command.

    SQL> alter user avauditorusr-name identified by avauditorusr-password;
    

Change the Password of the avadminusr User Name in the Audit Vault Server Home

To change the password of the avadminusr user name in the wallet location, use the AVCA create_credential command.

For example, to change password of the avadminusr user name, perform the following step in the Audit Vault Server home. To update the password for the credential, use the following AVCA create_credential command. Enter the avadminusr user name and new password and confirm the password. The database alias is the Audit Vault Server SID or Oracle instance identifier in the Audit Vault Server home. For example:

avca create_credential -wrl $ORACLE_HOME/network/admin/avwallet -dbalias SID
AVCA started
Storing user credentials in wallet... 
Enter source user username: avadminuser
Enter source user password: password
Re-enter source user password: password
Create credential Modify credential
Modify 2
done.

Change the Passwords of the avagentusr and srcusr User Name in the Audit Vault Collection Agent Home

To change the password of the avagentusr user name in the wallet location, use the AVCA create_credential command. To change the password of the srcusr user name in the wallet location, use the AVORCLDB setup command.

For example, to change the passwords of the avagentusr and srcusr user names, perform the following steps in the Audit Vault Collection Agent home: To update the avagentusr user name password, use the following AVCA create_credential command shown in Step 1. The database alias is always av in the Audit Vault Collection Agent home. To update the srcusr user name password, use the following AVORCLDB setup command shown in Step 2.

  1. Enter the avagentusr user name and new password and confirm the password. For example:

    avca create_credential -wrl $ORACLE_HOME/network/admin/avwallet -dbalias av
    AVCA started
    Storing user credentials in wallet... 
    Enter source user username: avagentuser
    Enter source user password: password
    Re-enter source user password: password
    Create credential Modify credential
    Modify 2
    done.
    
  2. Enter the srcusr user name and new password, where the source name is orcl1 and the source user name is srcuser1. For example:

    avorcldb setup -srcname orcl1
    Enter Source user name: srcuser1
    Enter Source password: *******
    adding credentials for user srcuser1 for connection [SRCDB1]
    Storing user credentials in wallet...
    Create credential oracle.security.client.connect_string3
    done.
    updated tnsnames.ora with alias [SRCDB1] to source database
    verifying SRCDB1 connection using wallet
    

Check To Ensure All Changed User Name Passwords Work Correctly

Always check to make sure all changed passwords for Audit Vault user names and source user names are working correctly. To check the passwords of the avadminusr and avauditorusr user name, open a Web browser and log in to the Audit Vault Console as the Audit Vault administrator. Then log out and log in to the Audit Vault Console as the Audit Vault auditor. A successful log in indicates that the new avadminusr and avauditor user name passwords are working fine. If your login is not successful after several attempts, repeat the steps previously mentioned in this section to change the password again for that particular Audit Vault user name and retry the login.

Next, stop the collection agent and collectors and start the collection agent and each collector. If the collection agent and the collectors each start up and collectors are collecting audit records again, the new avagntusr and srcusr user name passwords are all working.

If you experience problems, check the log files (see Chapter 6 for more information) to determine which user name password might be the source of the problem. Then, if needed, repeat the steps previously mentioned to change the password for that user name and try to start up the collection agent and the collectors again.

4.8 Back Up and Recovery of Oracle Audit Vault

Oracle Audit Vault patches do not have the ability to be rolled back, therefore you should take precautions to backup the files before any Oracle Audit Vault patch is applied until you have tested the patchset apply.

Back Up the Database

After cleanly shutting down the instance following the analysis of the database, you should perform a full backup of the database. Complete the following steps:

  1. Sign on to RMAN:

    rman "target / nocatalog"
    
  2. Issue the following RMAN commands:

    BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;
        BACKUP CURRENT CONTROLFILE TO 'save_controlfile_location';
    

    Caution:

    If you encounter problems with the upgrade and wish to abandon the upgrade completely, then you will need to restore the database from this backup. Therefore, make sure you back up your database now as a precaution.

    See Also:

    Oracle Database Backup and Recovery Basics for more information about backing up a database.

Back Up Audit Vault Server Home

Because the patchset will update files in the Audit Vault Server Home, these files should all be backed up or copied to another directory until the patchset has been tested.

Back Up Audit Vault Collection Agent Home

Because the patchset will update files in the Audit Vault Collection Agent Home, these files should be backed up or copied to another directory until the patchset has been tested.

Abandon the Upgrade

If the patchset apply is not successful, to abandon the upgrade, perform the following steps:

  1. Copy (Restore) the Audit Vault Server Home files back.

  2. Copy (Restore) the Audit Vault Collection Agent Home files back.

  3. If you completed the steps in Back Up the Database to back up your database, then restore that backup. Complete the following steps:

    1. Log in to the system as the owner of the Oracle home directory of the previous release.

    2. Sign on to RMAN:

      rman "target / nocatalog"
      
    3. Issue the following RMAN commands:

      STARTUP NOMOUNT
      RUN
      {
          REPLICATE CONTROLFILE FROM 'save_controlfile_location';
          ALTER DATABASE MOUNT;
          RESTORE DATABASE FROM TAG before_upgrade
          ALTER DATABASE OPEN RESETLOGS;
      }