Compensation Log Records (CLR) in UNDO-Phase of Database Recovery

Question

The compensation logs' redo-information corresponds to the undo-information of the log entry that made their creation necessary during the undo-phase.

That sounds to me like the CLRs redo information is the same as the undo information of the logs that sparked them.

But should't it be that they have the REDO information in order to cancel out the executed UNDO operations in case of an interrupted recovery process?

Here's an example:

let T2 be a loser transaction:

<#55, T2, P3, J=J+9, J = J-9, #53>

J=J+9 is the redo-op and J = J-9 is the undo-op.

Now the CLR that's appended to the Log file during the redo-phase would be:

<#56, T2, J=J-9,__, #53>

With J=J-9 being the undo-op of the original log entry as the redo information in the CLR. In case the recovery is interrupted, the log-entry #56 will be executed during redo phase.

The point of CLR is to ensure that restarting the recovery process and running it again always leads to the same result. How does running the J=J-9 operation during the redo phase of the rerun ensure this?

Can somebody please explain this to me?

Answer 1

Compensation log records (CLRs) are not written to the log during normal operation. They are produced while processing a rollback, either application-requested or due to a crash. Since their only use is during a rollback they need only hold enough information to perform that action i.e. J=J-9 from the example. Each CLR is paired to its corresponding original log record through a LSN reference.

The purpose of the redo phase of recovery is to return the database to the state it was in at the time of the crash. If that crash happened half way through a recovery then the second recovery's redo phase should leave the db as is was half way through the first recovery. The second recovery's redo phase processes the CLRs written by the first recovery's undo phase. Since CLRs are linked to the original update log records, knowing the last CLR processed tells the second recovery's undo phase which log record to jump to so it can complete the rollback.

To use the given example, the first recovery's undo phase will process log record #55's undo action (J = J-9) and create CLR #56. Then it will proceed backward to the previous linked record (#53). Let's say we crashed before it was processed. The second recovery's redo phase will process CLR #56's operation. If this is the last CLR the second recovery's undo phase will follow the link back to #53 and complete the rollback from there. Effectively #56 replaces #55 during the second and subsequent recoveries.

So why bother with all this? Why can't the second recovery simply do exactly what the first recovery did? Because Aries assumes a buffer manager using steal, no force policy. During the first recovery a page may have been partially rolled back and then swapped out of the buffer pool. So the second recovery is not starting from the same persisted state that the first one did, so it cannot simply perform the same actions a second time.