As Audit Process describes, with database server-managed auditing on UNIX, the database server writes audit records to audit files in an audit trail. This section describes the audit files in more detail.
The audit files are located in a directory that you specify with the onaudit utility or the ADTPATH configuration parameter in the $INFORMIXDIR/aaodir/adtcfg UNIX file.
Extended Parallel Server creates subdirectories for audit files in the path that you specify as the argument to the ADTPATH configuration parameter or as the argument to the onaudit -p command. The directory path that you specify must already exist on each node that hosts a coserver. For more information, refer to Audit File Names.
If you change the audit path, the change takes effect immediately for all existing sessions. This feature enables you to change the directory when the database server is in online mode, which is useful if the file system that contains the existing audit files becomes full.
Keep the file system that holds the audit trail cleaned out so that ample storage space is always available.
When the database server writes an audit record, the database server appends the record to the current audit file. If you bring the database server out of online mode and then put it back, the database server continues to use the same audit file. The database server starts a new audit file only under the following conditions:
The database server starts a new audit file at the default size of 10,240 bytes, which is the minimum size for audit files. (The adtcfg.std file might list a value of 50,000 bytes as a guideline.) You can change this file size at any time when auditing is on, even when the database server writes to an audit file, as Utility Syntax describes.
The optimal size for audit files depends on your configuration. Larger files contain more data, which results in fewer files to review. However, the trade-off is that large files are more difficult to manipulate.
No matter how you start a new audit file, it follows the same naming convention.
In both Dynamic Server and Extended Parallel Server, the naming convention is dbservername.integer, where dbservername is the database server name as defined in the ONCONFIG file, and integer is the next integer. The series starts with 0.
For example, if a new audit file is started for a database server maple, and the last audit file was saved in the file maple.123, then the next audit file is called maple.124. (If maple.124 already exists, the next available number is used.) The names are unique to a specific audit directory, so you can have auditdir1/maple.123 and auditdir2/maple.123, and so on.
Extended Parallel Server stores audit files locally on each coserver in a directory that you specify. For example, if you specify /disk1/audit as the location of audit files, the audit file directories and filenames would have the following form:
$disk1/audit/servername.coserver_id/servername.nnn
The variable servername.coserver_id combines the name of the database server defined in the ONCONFIG file and the number of the coserver that hosts the audit file. All audit files are stored locally on the coserver where the audited event occurs. Only one audit file directory exists for each coserver.
For example, if the database server is named beech, the audit files for coserver 3 are stored on a disk attached to the node that hosts coserver 3 in /disk1/audit/beech.3 and the audit files in the beech.3 directory have names such as beech.111, beech.112, and so on. If the node that hosts coserver 3 also hosts coserver 4, another directory named beech.4 is created under /disk1/audit to contain audit files for events that occur on coserver 4.