This document discusses recovery with concurrent transactions. It describes how to modify the log-based recovery scheme to support multiple concurrent transactions using a single disk buffer and log. During recovery, transactions in the undo list must be rolled back before transactions in the redo list are re-executed to restore consistency. Checkpoints record the active transactions to minimize log scanning during recovery.

1. RECOVERY WITH CONCURRENT
TRANSACTION
PRESENTED BY
M . LAVANYA
M.Sc(CS & IT)
NADAR SARASWATHI COLLEGE OF ARTS &SCIENCE
VADAPUDUPATTI , THENI.

2. INTRODUCTION
• Recovery in a single transaction at a time is executing
• We can modify and extend the log-based recovery scheme
with multiple concurrent transactions.
• The system has a single disk buffer and a single log.
• Immediate update and permit a buffer block to update the data
item.

3. INTERACTION WITH CONCURRENCY
CONTROL
• Concurrency control using strict two-phase locking:
how to perform undo if updates A , then t2 updates A and commits and
finally t1 h as to abort.
• Logging is done as
log records of different transactions may be interspersed in the log .
• The check pointing techniques and actions taken on recovery have to
be changed
several transactions may be active when a check point is performed.

4. Transaction Rollback
• Roll back a failed transaction, Ti, by using the log. The system scans
the log back- ward; for every log record of the form <Ti, Xj , V1, V2>
found in the log, the system restores the data item Xj to its old value
V1.
• Scanning of the log terminates when the log record <Ti, start> is found.
• Scanning the log backward is important, since a transaction may have
updated a data item more than once. As an illustration, consider the pair
of log records
<Ti, A, 10, 20>
<Ti, A, 20, 30>

5. Checkpoints
checkpoints to reduce the number of log records that the
system must scan when it recovers from a crash. Since we
assumed no concurrency, it was necessary to consider only the
following transactions during recovery:
• Those transactions that started after the most recent
checkpoint
• The one transaction, if any, that was active at the time of the
most recent check- point

6. • In a concurrent transaction-processing system, we require that
the checkpoint log record be of the form <checkpoint L>,
where L is a list of transactions active at the time of the
checkpoint.
• The requirement that transactions must not perform any
updates to buffer blocks or to the log during check pointing.
• A fuzzy checkpoint is a check- point where transactions are
allowed to perform updates even while buffer blocks

7. • The system constructs the two lists as follows: Initially, they
are both empty. The system scans the log backward, examining
each record, until it find the first.
<checkpoint> record:
• For each record found of the form <Ti commit>, it adds Ti to
redo-list.
• For each record found of the form <Ti start>, if Ti is not in
redo-list, then it adds Ti to undo-list.

8. The recovery proceeds as follows:
1. The system rescans the log from the most recent record
backward, and per- forms an undo for each log record that
belongs transaction Ti on the undo-list.
2. The system locates the most recent <checkpoint L> record on
the log. Notice that this step may involve scanning the log
forward, if the checkpoint record was passed in step 1.
3. The system scans the log forward from the most recent
<checkpoint L> record, and performs redo for each log record
that belongs to a transaction Ti that is on the redo-list.

9. • It is important to undo the transaction in the undo-list before redoing
transactions in the redo-list, using the algorithm in steps 1 to 3;
otherwise, a problem may occur. Suppose that data item A initially
has the value 10.
• another transaction Tj then updated data item A to 30 and
committed, following which the system crashed. The state of the log
at the time of the crash is
<Ti, A, 10, 20>
<Tj , A, 10, 30>
<Tj commit>