Aud:
Audit Commit Delay Exceeded, Written A Copy To Os Audit Trail
The problem is happening because the audit functionality was not able to commit an audit record within 5 seconds, this means at the time the message was written to the alert.log your database was under stress. The cause of the problem is not the auditing layer and the messages seen in the alert.log are only showing that the auditing is suffering because of the generic performance problems of the environment which might affect other components as well.
These messages are purely informational and no direct action can or should be taken to avoid them. This is most likely because of a resource problem on your database. If this is seen incidental you can ignore it but if these messages are seen regularly you will likely have a resource problem and also seeing other symptoms of that, you should analyze and solve the generic performance problem first and then these messages will also go away.
the fix to unpublished bug 8642202 changes the behaviour as follows:
Audit Commit Delay increased to 15 seconds and enforced only when AUD$ is initialized for cleanup.
Bug 8642202 is fixed in patchset 10.2.0.5, PSU 11.2.0.1.1 and patchset 11.2.0.2 and future releases.
Merge patches that include this fix:
11.1.0.7: Patch 9821987
You see the following
messages appear in your alert.log:
AUD: Audit Commit
Delay exceeded, written a copy to OS Audit Trail
This is a change that
was introduced within the audit functionality to support Audit Vault, these
messages can appear in your alert.log occasionally even if this database is not
a source of Audit Vault, the reason is as follows:
The database will guarantee that the transaction writing the audit record will commit within a pre-defined maximum allowed interval which is called the Audit Commit Delay interval. If the transaction takes more than Audit Commit Delay to commit the audit record, the Database will write the same record to the OS audit trail. This is a fallback mechanism to make sure there's always written evidence of an audited action within the defined timeframe, a such it is a feature to enhance audit security. The commit delay is fixed at 5 seconds and cannot be tuned.
The database will guarantee that the transaction writing the audit record will commit within a pre-defined maximum allowed interval which is called the Audit Commit Delay interval. If the transaction takes more than Audit Commit Delay to commit the audit record, the Database will write the same record to the OS audit trail. This is a fallback mechanism to make sure there's always written evidence of an audited action within the defined timeframe, a such it is a feature to enhance audit security. The commit delay is fixed at 5 seconds and cannot be tuned.
The problem is happening because the audit functionality was not able to commit an audit record within 5 seconds, this means at the time the message was written to the alert.log your database was under stress. The cause of the problem is not the auditing layer and the messages seen in the alert.log are only showing that the auditing is suffering because of the generic performance problems of the environment which might affect other components as well.
These messages are purely informational and no direct action can or should be taken to avoid them. This is most likely because of a resource problem on your database. If this is seen incidental you can ignore it but if these messages are seen regularly you will likely have a resource problem and also seeing other symptoms of that, you should analyze and solve the generic performance problem first and then these messages will also go away.
the fix to unpublished bug 8642202 changes the behaviour as follows:
Audit Commit Delay increased to 15 seconds and enforced only when AUD$ is initialized for cleanup.
Bug 8642202 is fixed in patchset 10.2.0.5, PSU 11.2.0.1.1 and patchset 11.2.0.2 and future releases.
Merge patches that include this fix:
11.1.0.7: Patch 9821987
