Administering the Oracle ASM Audit Trail

The number of audit trail files in the audit destination directories for an Oracle ASM, IOServer, or APX proxy instance can grow very large if the directories are not regularly maintained. To control the number of these files, auditing can be managed with operating system tools, such as the Syslog facility on UNIX platforms.

Managing Instance Audit Records With Syslog

The audit records directed to the Syslog facility should remain separated from other system generated audit records in the system. To ensure that separation, set the configuration values in /etc/syslog.conf so that only Oracle audit records are written to a given file.

For example, you could choose to set the /var/log/oracle/oracleaudit.log file exclusively for Oracle audit records with the following setting in the syslog.conf file:

# Log all Oracle audit records.
LOCAL7.ALERT 	/var/log/oracle/oracleaudit.log

The syslog daemon should be restarted to pick up the changes in the syslog configuration file. The restart operation requires super user (root) privileges on the machine. For example:

# /etc/rc.d/init.d/syslog restart

After setting up the entry in the syslog configuration file, set the AUDIT_SYSLOG_LEVEL initialization parameter in the Oracle ASM, IOServer, or APX proxy instance parameter file to the same value (AUDIT_SYSLOG_LEVEL = LOCAL7.ALERT) and restart the instance.

See Also:

  • Articles at My Oracle Support (https://support.oracle.com) for information about managing Oracle ASM, IOServer, or APX proxy instance auditing. For example:

    • Manage ASM Audit Files with syslog (Doc ID 1559573.1)

    • Manage Audit File Directory Growth with cron (Doc ID 1298957.1)

    • AUDIT_SYS_OPERATIONS Set To FALSE Yet Audit Files Are Generated (308066.1)

    • Init.ora Parameter "AUDIT_FILE_DEST" Reference Note (39796.1)

  • Oracle Database Reference for information about the AUDIT_SYSLOG_LEVEL initialization parameter.