Understanding the Audit Operation
The auditdb command lets you produce a listing or file of changes made to journaled tables after the last checkpoint. This listing may not include all changes that have been made after the last checkpoint for the following reasons:
• Because auditdb does not exclusively lock the database, other users can complete a transaction while the audit is running.
• If other users are using the database when you perform an audit, a completed transaction may not have been moved to the journal files.
The audit database operation scans journal files twice. A prescan is performed to filter out undesired information (for example, aborted transaction data). The second scan outputs journal records of interest. To improve program performance, the -e option (Before edit control value in VDBA) terminates both scans when an End Transaction record is found that has a time later than that specified.
Note: The -inconsistent option lets you view journals that the database has marked as inconsistent. The audit database operation can still fail if core catalogs are inconsistent.
The -wait option makes the audit wait until journals are current. “Current” in this context means either of the following:
• No further archiving is required on the database.
• The archiver has copied all log file information up to the log file end-of-file when the audit database request was initiated.
Note: If a large amount of unarchived information remains in the log file when this request is initiated, a significant delay in processing can occur.