A tracking log captures the sequence of modifications that have been applied to a single table, the table being tracked. The tracking log allows the monitored table to be reconstructed as of any time in the past. This feature can be used to undo inadvertent modifications or to restore the table to a previous, consistent state. Of course, the tracking log can also be used in informal or formal audit procedures.

Different organizations of the tracking log result from the varying assumptions and constraints on the monitored table. The schema of the tracking log comprises the columns of the monitored table, along with a timestamp column (a single datetime specifying when the modification occurred) and sometimes an operation code (insert, delete, update) and a transaction identifier. Triggers can be used to maintain the tracking log, without necessitating changes to the application code. A tracking log can contain before-images (the row before the indicated change occurred), after-images, or a combination of both.

The different organizations of the tracking log are coupled with various reconstruction algorithms. Achieving fully accurate transaction semantics for the reconstructed table turns out to be surprisingly difficult; various restrictions on how the monitored trail is modified can simplify the reconstruction algorithm dramatically.