现象:
In Oracle Database 11gR1 and 11gR2:
One may find a large number of OS audit trail files, ending in .aud, being generated on the filesystem in AUDIT_FILE_DEST.
These files can be very small: less than 1KB in size.
The names of these files often share an OS PID number, such as:
rdbms_ora_663_1.aud
rdbms_ora_663_2.aud
rdbms_ora_663_3.aud
What are possible reasons for these files being created with such frequency?
原因:
As of Oracle Database 11g, audit file generation is a function of the following:
New Sessions
When a new database session reuses an OS PID, and the session generates OS audit trail records, these records are no longer appended to the end of a pre-existing .aud file containing the previously-used PID.
Each new session (that is audited) will always have a new .aud file created on the filesystem, and is currently distinguished from other sessions using the same PID by a "sequence" character in the filename.
For example:
rdbms_ora_663_1.aud
rdbms_ora_663_2.aud
...
rdbms_ora_663_f.aud
The generation of separate files cannot be changed in the case where every file represents a new session; this is not configurable.
For performance reasons, the audit file naming convention may be altered in future versions of Oracle Database.
Connecting as SYSDBA
SYSDBA connections to the database always result in .aud files being generated. If there are many distinct SYSDBA connections taking place, such as with ASM, Restart, or RMAN, then one can expect to see many .aud files being written.
This behavior is independent of the setting of AUDIT_SYS_OPERATIONS or even AUDIT_TRAIL.
See also:
Note 1378881.1 - Large Number of Audit Files Generated by Oracle Restart or Grid Infrastructure
Note 1211396.1 - Large Number Of Audit Files Generated During Rman Backups
Note 308066.1 - AUDIT_SYS_OPERATIONS Set To FALSE Yet Audit Files Are Generated
DBMS_AUDIT_MGMT
When using DBMS_AUDIT_MGMT, there is a parameter that controls the size of OS audit trail files: DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE. This specifies the maximum size, in kilobytes (KB), to which an OS (or XML) audit file can grow before a new file is opened.
Audit files can still be smaller than this maximum size, depending on how many audit records are written for a given session.
This parameter will NOT cause multiple sessions which reuse an OS PID to be concatenated into larger files.
However, on 11gR1, there is a bug involving DBMS_AUDIT_MGMT that can cause same-session activity to be split into multiple, very small .aud files, triggered by the abnormal termination of a session (see below).
处理方法:
The number and size of .aud files may actually constitute expected behavior, given the current design and the nature/volume of database sessions for a particular database.
To determine this, review the following points:
1) Evaluate the auditing setup for the database, so that one understands the circumstances that will cause audit trail records to be written to the operating system.
2) Examine the .aud files in AUDIT_FILE_DEST, and summarize the types of records contained in the files.
3) Assess the types and volume of connections to the database. Is there an application that reconnects very frequently (thousands to millions of times per day)? Are there cron jobs, RMAN backups, Enterprise Manager Agents? Is this an ASM database?
4) Is the database on 11gR1 or 11gR2? If 11gR1, Unpublished Bug 7427320 may be a factor; the bug is fixed on 11gR2. Refer to:
Note 804624.1 - Known Issues When Using: DBMS_AUDIT_MGMT
5) For further discussion of audit record generation (including but not restricted to the OS audit trail), see also:
<Note 1171314.1> - Huge/Large/Excessive Number Of Audit Records Are Being Generated In The Database
|