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.