checkpointing is possible since physical redo log records are generated by all updates these are used during restart recovery and their effects are idempotent for any uncommitted update whose effects have made it to the checkpoint image undo log records are written out to disk after the database image has been written this is performed by checkpointing the att after checkpointing the data the checkpoint of the att writes out undo log records as well as other status information at the end of checkpointing a log flush must be done before declaring the checkpoint completed and consistent by toggling cur_ckcp to point to the new checkpoint this is because undo logs are deleted on transaction operation pre commit which may happen before the checkpoint of the att if the checkpoint completes and the system then fails before a log flush then the checkpoint may contain uncommitted updates for which there is no undo information the log flush ensures that the transaction operation has committed and so the updates will not have to be undone except perhaps by a compensating operation for which undo information will be present in the log when a transaction aborts i e fails to complete execution successfully updates operations described by log records in the transaction 39 s undo log are undone by traversing the undo log sequentially from the.