Summary information |
|
|---|---|
Default value |
100 |
Range of values |
1–65535 |
Status |
Dynamic |
Display level |
Intermediate |
Required role |
System Security Officer |
The in-memory audit queue holds audit records generated by user processes until the records can be processed and written to the audit trail. A System Security Officer can change the size of the audit queue with audit queue size. There is a trade-off between performance and risk that must be considered when you configure the queue size. If the queue is too large, records can remain in it for some time. As long as records are in the queue, they are at risk of being lost if the system crashes. However, if the queue is too small, it can become full repeatedly, which affects overall system performance–user processes that generate audit records sleep if the audit queue is full.
Following are some guidelines for determining how big your audit queue should be. You must also take into account the amount of auditing to be done at your site.
The memory requirement for a single audit record is 424 bytes; however a record can be as small as 22 bytes when it is written to a data page
The maximum number of audit records that can be lost in a system crash is the size of the audit queue (in records), plus 20. After records leave the audit queue they remain on a buffer page until they are written to the current audit table on the disk. The pages are flushed to disk every 20 records at the most (less if the audit process is not constantly busy).
In the system audit tables, the extrainfo field and fields containing names are of variable length, so audit records that contain complete name information are generally larger.
The number of audit records that can fit on a page varies from 4 to as many as 80 or more. The memory requirement for the default audit queue size of 100 is approximately 42K.
