CO4

Database Recovery Techniques

Recovery techniques are those techniques that can be used for database recovery in case of
system failure. Recovery from transaction failures usually means that the database is restored
to the most recent consistent state before the time of failure. To do this, the system must keep
information about the changes that were applied to data items by the various transactions. This
information is typically kept in the system log.
We can distinguish two main policies for recovery from transaction failures:
• Deferred update (NO-UNDO/REDO algorithm)
• Immediate update (UNDO/REDO algorithm)
The most widely used structure for recording database modifications is the log. The log is a
sequence of log records, recording all the update activities in the Database. There are several
types of log records. An update log record describes a single database write. It has these fields:
• Transaction identifier, which is the unique identifier of the transaction that performed
the write operation.
• Data-item identifier, which is the unique identifier of the data item written. Typically,
it is the location on disk of the data item, consisting of the block identifier of the block
on which the data item resides, and an offset within the block.
• Old value, which is the value of the data item prior to the write.
• New value, which is the value that the data item will have after the write.
We represent an update log record as <Ti , Xj , V1, V2>, indicating that transaction Ti has
performed a write operation on data item Xj . Xj had value V1 before the write, and has value
V2 after the write. Other special log records exist to record significant events during transaction
processing, such as the start of a transaction and the commit or abort of a transaction. Among
the types of log records are:
• <Ti start> Transaction Ti has started.
• <Ti commit> Transaction Ti has committed.
• <Ti abort> Transaction Ti has aborted.
Whenever a transaction performs a write, it is essential that the log record for that write be
created and added to the log, before the database is modified. Once a log record exists, we can
output the modification to the database if that is desirable.
If a transaction does not modify the database until it has committed, it is said to use the
deferred-modification technique. If database modifications occur while the transaction is still
active, the transaction is said to use the immediate-modification technique.
Because all database modifications must be preceded by the creation of a log record, the system
has available both the old value prior to the modification of the data item and the new value
that is to be written for the data item. This allows the system to perform undo and redo
operations as appropriate.
• Undo using a log record sets the data item specified in the log record to the old value.
• Redo using a log record sets the data item specified in the log record to the new value.

DEFERRED DATABASE MODIFICATION

The deferred-modification technique ensures transaction atomicity by recording all database
modifications in the log, but deferring the execution of all write operations of a transaction
until the transaction partially commits. Observe that only the new value of the data item is
required by the deferred modification technique. To illustrate, reconsider our simplified
banking system. Let T0 be a transaction that transfers $50 from account A to account B and
Let T1 be a transaction that withdraws $100 from account C:

Suppose that these transactions are executed serially, in the order T0 followed by T1, and that
the values of accounts A, B, and C before the execution took place were $1000, $2000, and
$700, respectively. The portion of the log containing the relevant information on these two
transactions appears in Figure.

The recovery scheme uses the following recovery procedure: redo(Ti) sets the value of all
data items updated by transaction Ti to the new values.
If the system crashes before the completion of the transactions, so that we can see how the
recovery technique restores the database to a consistent state. Assume that the crash occurs
just after the log record for the step write(B) of transaction T0 has been written to stable
storage. The log at the time of the crash appears in Figure.

When the system comes back up, no redo actions need to be taken, since no commit record
appears in the log. The values of accounts A and B remain $1000 and $2000, respectively.
The log records of the incomplete transaction T0 can be deleted from the log.
Now, let us assume the crash comes just after the log record for the step write(C) of transaction
T1 has been written to stable storage. In this case, the log at the time of the crash is as in Figure.
When the system comes back up, the operation redo(T0) is performed, since the record <T0
commit> appears in the log on the disk.

When the system comes back up, the operation redo(T0) is performed, since the record <T0
commit> appears in the log on the disk.

IMMEDIATE DATABASE MODIFICATION

The immediate-modification technique allows database modifications to be output to the
database while the transaction is still in the active state. In the event of a crash or a transaction
failure, the system must use the old-value field of the log records also. As an illustration, let us
reconsider our simplified banking system, with transactions T0 and T1 executed one after the
other in the order T0 followed by T1.
The recovery scheme uses two recovery procedures:
• Undo (Ti) restores the value of all data items updated by transaction Ti to the old values.
• Redo (Ti) sets the value of all data items updated by transaction Ti to the new values.
The set of data items updated by Ti and their respective old and new values can be found in the
log.
• Transaction Ti needs to be undone if the log contains the record <Ti start>, but does
not contain the record <Ti commit>.
• Transaction Ti needs to be redone if the log contains both the record <Ti start> and the
record <Ti commit>.
Return to our banking example, with transaction T0 and T1 executed one after the other in the
order T0 followed by T1. Suppose that the system crashes before the completion of the
transactions. First, let us assume that the crash occurs just after the log record for the step
write(B). of transaction T0 has been written to stable storage.

When the system comes back up, it finds the record <T0 start> in the log, but no corresponding
<T0 commit> record. Thus, transaction T0 must be undone, so an undo(T0) is performed.
Next, let us assume that the crash comes just after the log record for the step write(C) of
transaction T1 has been written to stable storage.

When the system comes back up, two recovery actions need to be taken. The operation
undo(T1) must be performed, since the record <T1 start> appears in the log, but there is no
record <T1 commit>. The operation redo(T0) must be performed, since the log contains both
the record <T0 start> and the record <T0 commit>.
CHECKPOINTS

The checkpoint is a type of mechanism where all the previous logs are removed from the system
and permanently stored in the storage disk. The checkpoint is like a bookmark. While the
execution of the transaction, such checkpoints are marked, and the transaction is executed then
using the steps of the transaction, the log files will be created.
When it reaches to the checkpoint, then the transaction will be updated into the database, and
till that point, the entire log file will be removed from the file. Then the log file is updated with
the new step of transaction till next checkpoint and so on. The checkpoint is used to declare a
point before which the DBMS was in the consistent state, and all transactions were committed.

Steps to Use Checkpoints in the Database

1. Write the begin_checkpoint record into a log.
2. Collect checkpoint data in stable storage.
3. Write the end_checkpoint record into a log.

The behavior when the system crashes and recovers when concurrent transactions are executed
is shown below:

• The recovery system reads the logs backward from the end to the last checkpoint i.e.
from T4 to T1.
• It will keep track of two lists – Undo and Redo.
• Whenever there is a log with instructions <Tn, start>and <Tn, commit> or only <Tn,
commit> then it will put that transaction in Redo List. T2 and T3 contain <Tn, Start>
and <Tn, Commit> whereas T1 will have only <Tn, Commit>. Here, T1, T2, and T3
are in the redo list.
• Whenever a log record with no instruction of commit or abort is found, that transaction
is put to Undo List <Here, T4 has <Tn, Start> but no <Tn, commit> as it is an ongoing
transaction. T4 will be put on the undo list.

All the transactions in the redo list are deleted with their previous logs and then redone before
saving their logs. All the transactions in the undo list are undone and their logs are deleted.
SHADOW PAGING
Shadow paging considers the database to be made up of a number of fixed size disk pages (or
disk blocks)—say, n—for recovery purposes. A directory with n entries is constructed, where
the i th entry points to the i th database page on disk.
When a transaction begins executing, the current directory is copied into a shadow directory.
The shadow directory is then saved on disk while the current directory is used by the
transaction. During transaction execution, the shadow directory is never modified. When a
write_item operation is performed, a new copy of the modified database page is created, but
the old copy of that page is not overwritten. Instead, the new page is written elsewhere—on
some previously unused disk block.
The current directory entry is modified to point to the new disk block, whereas the shadow
directory is not modified and continues to point to the old unmodified disk block.

• To recover from a failure during transaction execution, it is sufficient to free the

modified database pages and to discard the current directory.
• Committing a transaction corresponds to discarding the previous shadow directory.
ARIES ALGORITHM

Algorithm for Recovery and Isolation Exploiting Semantics (ARIES) starts by finding log
records for operations that were not written to disk on crash and then replays all of them. This
even includes transactions that need to rolled back. It brings the database to the same state as
it was before crash. This process is called “repeating history”. Note that this is same mechanism
that is used for database replication in normal course of action. Once database is brought up to
date, all the transactions that need to be rolled back are undone.

ARIES is a three-phase algorithm:

1. Analysis phase: This phase reads the last checkpoint record in the log to figure out
active transactions and dirty pages at point of crash/restart. A page is considered dirty
if it was modified in memory but was not written to disk. This information is used by
next two phases.

2. REDO phase: In this phase operations in log are reapplied to bring the state of the
database to current.

3. UNDO phase: This phase proceeds from the end of log reverting back operations for
uncommitted transactions. This has impact of rolling them back. Note that this is same
procedure that database performs when rolling back a transaction in normal mode of
operation for STEAL policy.

ARIES maintains two data structures and adds one more field to log record:

1. Transaction table: It contains all the transactions that are active at any point of time
(i.e. are started but not committed/aborted). The table also stores the LSN of last log
record written by the transaction in “lastLSN” field.

2. Dirty page table: Contains an entry for each page that has been modified but not
written to disk. The table also stores the LSN of the first log record that made the
associated page dirty in a field called “recoveryLSN” (also called “firstLSN”). This is
the log record from which REDO need to restart for this page.

3. In addition log records are also updated to contain a field called “prevLSN” which
points to previous log record for the same transaction. This creates a linked list of all
log records for a transaction. When a new log record is created, “lastLSN” from
transaction table is filled into its “prevLSN” field. And the LSN of current log record
becomes the “lastLSN” in transaction table. Here is updated log record table with
prevLSN filled in:
During checkpointing, a checkpoint log record is created. This log record contains the content
of both “Transaction table” and “Dirty page table”. “Analysis” phase starts by reading last
checkpoint log record to get the information about active transactions and dirty pages. Here is
content of “Transaction table” and “Dirty page table” at the checkpoint stage in above table at
LSN 4: