K2B Audit can store audit information as Live records and Archived records. Both formats are equivalent in terms of the data they store, but have major differences in terms of storage, performance analysis, etc.
Database triggers generate a Live record for each operation on every audited table. The Audit archive process converts Live records into Archived records. Therefore, the audit record for a single database operation is stored either in a Live record or in a Archived one. Not both.
An installation can have Live records only, and never convert them to Archived ones or, a combination of Live and Archived records by executing the Archive process on a regular basis.
The following table may help the developer decide what approach matches an installation requirements the best.
| |
Live records |
Archived records |
Notes |
| Audit data availability |
Immediate, after each database operation |
After running Audit archive process |
|
| Basic analysis performance |
Normal |
High |
Analysis based on table names, user, etc. Not by attribute's values. |
| Deep analysis performance |
Mid to very low |
High |
For Live records, analysis including attribute's values requires searching in an XML structure. This search is NOT performed in the database server and performs far worst than searching in Archive records. |
| Storage requirements |
High |
Normal |
Normalized data always requires less storage space. Live records always require more space than Archived ones. The actual improvement varies among applications as it depends, for example, on the length of attribute names, their values, etc.
|
| Attribute rename support |
No |
Yes |
When an attribute is renamed Live records start recording values for the new name and stop for the previous name. No relationship is stored in the audit data that represents the rename.
The Archive process uses audit metadata to recognize the rename so that further analysis shows the new attribute name and the change history includes changes done before rename.
|
|