Chapter Two

Database Recovery
Techniques
Database Recovery
Process of restoring database to a correct state in the event of a failure.

Purpose of Database Recovery

To bring the database into the last consistent state, which existed prior to the failure.
To preserve transaction properties (Atomicity, Consistency, Isolation and Durability).

Example:
If the system crashes before a fund transfer transaction completes its execution, then
either one or both accounts may have incorrect value.
Thus, the database must be restored to the state before the transaction modified any of
the accounts.

Database Recovery Techniques 2

Types of Failure
(What causes a Transaction to fail)
1. A computer failure (system crash):
• A hardware or software error occurs in the computer system during transaction
execution. If the hardware crashes, the contents of the computer’s internal
memory may be lost.
2. A transaction or system error:
• Some operation in the transaction may cause it to fail, such as integer overflow
or division by zero. Transaction failure may also occur because of erroneous
parameter values or because of a logical programming error. In addition, the
user may interrupt the transaction during its execution.
3.Local errors or exception conditions detected by the transaction:
• Certain conditions necessitate cancellation of the transaction. For example,
data for the transaction may not be found. A condition, such as insufficient
account balance in a banking database, may cause a transaction, such as a fund
withdrawal from that account, to be canceled.
• A programmed abort in the transaction causes it to fail.

Slide 17- 3
Database Recovery Techniques
4. Concurrency control enforcement:
 The concurrency control method may decide to abort the transaction, to be restarted
later, because it violates serializability or because several transactions are in a state
of deadlock
5.Disk failure:
 Some disk blocks may lose their data because of a read or write malfunction or
because of a disk read/write head crash. This may happen during a read or a write
operation of the transaction.
6. Physical problems and catastrophes:
 This refers to an endless list of problems that includes power or air-conditioning
failure, fire, theft, sabotage, overwriting disks or tapes by mistake, and mounting of
a wrong tape by the operator.

Database Recovery Techniques 4

• When a DBMS recovers from a crash, it should maintain the following
• It should check the states of all the transactions, which were being executed.
• A transaction may be in the middle of some operation; the DBMS must ensure
the atomicity of the transaction in this case.
• It should check whether the transaction can be completed now or it needs to be
rolled back.
• No transactions would be allowed to leave the DBMS in an inconsistent state.
Log-based Recovery
• Log is a sequence of records, which maintains the records of actions
performed by a transaction. It is important that the logs are written prior to the
actual modification and stored on a stable storage media, which is failsafe.
• Log-based recovery works as follows −
• The log file is kept on a stable storage media.
• When a transaction enters the system and starts execution, it writes a log about it.
Recovery manager keeps track of the following operations:
•begin_transaction: This marks the beginning of transaction execution.
<Tn, Start>
•read or write: These specify read or write operations on the database items that
are executed as part of a transaction.
<Tn, X, V1, V2> It reads Tn has changed the value of X, from V1 to V2.

•end_transaction: This specifies that read and write transaction operations have
ended and marks the end limit of transaction execution.
•At this point it may be necessary to check whether the changes introduced by the
transaction can be permanently applied to the database or whether the transaction
has to be aborted because it violates concurrency control or for some other reason.
•commit_transaction: This signals a successful end of the transaction so that any
changes (updates) executed by the transaction can be safely committed to the
database and will not be undone.
<Tn, commit>
•rollback (or abort): This signals that the transaction has ended unsuccessfully, so
that any changes or effects that the transaction may have applied to the database
must be undone. Database Recovery Techniques 7
The System Log
Log or Journal: The log keeps track of all transaction operations that affect the
values of database items.
This information may be needed to permit recovery from transaction failures.
The log is kept on disk, so it is not affected by any type of failure except for
disk or catastrophic failure.
In addition, the log is periodically backed up to archival storage (tape) to
guard against such catastrophic failures.
• T in the following discussion refers to a unique transaction-id that is generated
automatically by the system and is used to identify each transaction:
• Types of log record:
• [start_transaction,T]: Records that transaction T has started execution.
• [write_item,T,X,old_value,new_value]: Records that transaction T has
changed the value of database item X from old_value to new_value.
• [read_item,T,X]: Records that transaction T has read the value of database
item X.
• [commit,T]: Records that transaction T has completed successfully, and
affirms that its effect can be committed (recorded permanently) to the
database.
• [abort,T]: Records that transaction T has been aborted.
Database Recovery Techniques 8
Sample log file
 Back P and Next P point to the previous and next log records of the same
transaction.
 Before-image of data item (BIMG)
 After-image of data item (AFIMG)

T ID Back P Next P Operation Data item BFIM AFIM

T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End

Database Recovery Techniques 9

• Recovery techniques use the following operators:
• undo: Similar to rollback except that it applies to a single operation rather than to a whole transaction.
• redo: This specifies that certain transaction operations must be redone to ensure that all the operations
of a committed transaction have been applied successfully to the database.
Commit Point of a Transaction:
• Definition a Commit Point:
• A transaction T reaches its commit point when all its operations that access the database have been
executed successfully and the effect of all the transaction operations on the database has been recorded
in the log.
• Beyond the commit point, the transaction is said to be committed, and its effect is assumed to be
permanently recorded in the database.
• The transaction then writes an entry [commit,T] into the log.
• Roll Back of transactions:
• Needed for transactions that have a [start_transaction,T] entry into the log but no commit entry
[commit,T] into the log.

Database Recovery Techniques 10

• Redoing transactions:
• Transactions that have written their commit entry in the log must also have recorded
all their write operations in the log; otherwise they would not be committed, so their
effect on the database can be redone from the log entries. (Notice that the log file
must be kept on disk.
• At the time of a system crash, only the log entries that have been written back to disk
are considered in the recovery process because the contents of main memory may be
lost.)
• Force writing a log:
• Before a transaction reaches its commit point, any portion of the log that has not been
written to the disk yet must now be written to the disk.
• This process is called force-writing the log file before committing a transaction.

Database Recovery Techniques 11

Data Update
Immediate Update: As soon as a data item is modified in cache, the disk copy is
updated.
• the database may be updated by some operations of a transaction before the transaction
reaches its commit point
• these operations are typically recorded in the log on disk by force writing before they
are applied to the database
• If a transaction fails after recording some changes in the database but before reaching
its commit point, the effect of its operations on the database must be undone
• both undo and redo may be required during recovery (known as the UNDO/REDO
algorithm)

Database Recovery Techniques

12
Deferred Update
• All modified data items in the cache is written either after a transaction ends its
execution or after a fixed number of transactions have completed their execution.
•The deferred update techniques do not physically update the database on disk until
after a transaction reaches its commit point; then the updates are recorded in the
database
•Before reaching commit, all transaction updates are recorded in the local
transaction workspace (or buffers).
•During commit, the updates are first recorded persistently in the log and then
written to the database.
•If a transaction fails before reaching its commit point, it will not have changed the
database in any way, so UNDO is not needed.
•It may be necessary to REDO the effect of the operations of a committed
transaction from the log, because their effect may not yet have been recorded in the
database.
•Hence, deferred update is also known as the NO-UNDO/ REDO algorithm.
Database Recovery Techniques 13
Shadow update:
• The modified version of a data item does not overwrite its disk
copy but is written at a separate disk location.
In-place update:
• The disk version of the data item is overwritten by the cache
version

Database Recovery Techniques 14

Transaction Roll-back (Undo) and Roll-Forward (Redo)
• To maintain atomicity, a transaction’s operations are redone or undone.
• Undo: Restore all BFIMs on to disk (Remove all AFIMs).
• Redo: Restore all AFIMs on to disk.
• Database recovery is achieved either by performing only Undos or only Redos
or by a combination of the two. These operations are recorded in the log as
they happen.

Slide 19- 15
Database Recovery Techniques
Write-Ahead Logging (WAL)
• Any change to a database object is first recorded in the log; the record in the log must
be written to stable storage before the change to the database object is written to
disk.
• When in-place update (immediate or deferred) is used then log is necessary for
recovery and it must be available to recovery manager. This is achieved by Write-
Ahead Logging (WAL) protocol.
WAL states that:
• For Undo: Before a data item’s AFIM is flushed to the database disk (overwriting
the BFIM) its BFIM must be written to the log and the log must be saved on a
stable store (log disk).
• For Redo: Before a transaction executes its commit operation, all its AFIMs must
be written to the log and the log must be saved on a stable store.

Database Recovery Techniques 16

Checkpointing
• Point of synchronization between database and log file. All buffers are force-
written to secondary storage.
• The time at which the database flushes its buffer to database disk to minimize the
task of recovery.
• Checkpoint record is created containing identifiers of all active transactions.
• When failure occurs, redo all transactions that committed since the checkpoint
and undo all transactions active at time of crash.
 The following steps defines a checkpoint operation:
1. Suspend execution of transactions temporarily.
2. Force write modified buffer data to disk.
3. Write a [checkpoint] record to the log, save the log to disk.
4. Resume normal transaction execution.
 During recovery redo or undo is required to transactions appearing after
[checkpoint] record.
Slide 19- 17
Database Recovery Techniques
Steal/No-Steal and Force/No-Force
 Possible ways for flushing database cache to database disk:
1. Steal: Cache can be flushed before transaction commits.
2. No-Steal: Cache cannot be flushed before transaction commit.
3. Force: Cache is immediately flushed (forced) to disk.
4. No-Force: Cache is deferred until transaction commits
 These give rise to four different ways for handling recovery:
 Steal/No-Force (Undo/Redo)
 Steal/Force (Undo/No-redo)
 No-Steal/No-Force (Redo/No-undo)
 No-Steal/Force (No-undo/No-redo)

Slide 19- 18
Database Recovery Techniques
Recovery Schemes
RECOVERY TECHNIQUES BASED ON DEFERRED UPDATE (No Undo/Redo)

• The idea behind deferred update techniques is to defer or postpone any actual updates
to the database until the transaction completes its execution successfully and reaches its
commit point.
• During transaction execution, the updates are recorded only in the log and in the cache
buffers
• After the transaction reaches its commit point and the log is force-written to disk, the
updates are recorded in the database.
• We can state a typical deferred update protocol as follows:
1. A transaction cannot change the database on disk until it reaches its commit point.
2. A transaction does not reach its commit point until all its update operations are
recorded in the log and the log is force-written to disk ( write-ahead logging (WAL)
protocol)
Slide 19- 19
• The data update goes as follows:
• A set of transactions records their updates in the log.
• At commit point under WAL scheme these updates are saved on database disk.
• After reboot from a failure the log is used to redo all the transactions affected by this
failure.
• No undo is required because no AFIM is flushed to the disk before a transaction
commits.
• Because the database is never updated on disk until after the transaction commits, there
is never a need to UNDO any operations.
• Hence, this is known as the NO UNDO/ REDO recovery algorithm
• REDO is needed in case the system fails after a transaction commits but before all its
changes are recorded in the database on disk.
• In this case, the transaction operations are redone from the log entries.

Database Recovery Techniques 20

Deferred Update in a single-user system
•There is no concurrent data sharing in a single user system.
•The data update goes as follows:
• A set of transactions record their updates in the log.
• At commit point under WAL scheme, these updates are saved on database
disk.
•After reboot from a failure the log is used to redo all the transactions affected by
this failure.
•No undo is required because no AFIM is flushed to the disk before a transaction
commits.

Slide 19- 21
• Deferred Update in a single-user Environment
• Uses two lists of transactions:
• List of all committed transactions since the last checkpoint
• List of all active transactions since the last checkpoint (At most one active transaction would have
failed in a single user environment)
• Logs maintained in the form:
write_item(T,X,new_value)
Algorithm:
1.Redo all committed transactions since the last checkpoint(Update all the corresponding
data elements that have been logged)
2. Restart all the active transactions(Note that none of the active transactions would have
actually changed data elements due to deferred update policy)
Slide 19- 23
Deferred Update with concurrent users
•This environment requires some concurrency control mechanism to guarantee isolation
property of transactions.
• In a system recovery transactions which were recorded in the log after the last checkpoint
were redone.
• The recovery manager may scan some of the transactions recorded before the checkpoint to
get the AFIMs.
•Two tables are required for implementing this protocol:
• Active table: All active transactions are entered in this table.
• Commit table: The committed Transactions since the last checkpoint are entered in this table.
•During recovery, all transactions of the commit table are redone and all transactions of
active tables are ignored since none of their AFIMs reached the database.
•It is possible that a commit table transaction may be redone twice but this does not create
any inconsistency because of a redone is “idempotent”, that is, one redone for an AFIM is
equivalent to multiple redone for the same AFIM.
Slide 19- 24
Recovery in a multiuser Environment using Strict 2PL
Algorithm:
Make 2 lists:
• List of all committed transactions since the last checkpoint
• List of all active transactions since the last checkpoint (At most one active transaction
would have failed in a single user environment)
1.Redo the write operations of committed transactions in the same order as they
appear in the log
2. Release all the locks held by active transactions and Restart theses
transactions once again.(Note that none of the active transactions would have
actually changed data elements due to deferred update policy)
Database Recovery Techniques 26
Slide 19- 27
RECOVERY TECHNIQUES BASED ON IMMEDIATE UPDATE
(Undo/Redo Algorithm)

In these techniques, when a transaction issues an update command, the database can
be updated "immediately," without any need to wait for the transaction to reach its
commit point.
Update operation must still be recorded in the log (on disk) before it is applied to the
database-using the write-ahead logging protocol-so that we can recover in case of
failure.
The DB may be updated by some operations of a transaction before the transaction
reaches it’s commit point.
The updates are recorded in the log must contain the old values and new values.
These techniques need to undo the operations of the uncommitted transactions and
redo the operations of the committed transactions .

Database Recovery Techniques 28

Undo Operations

•Need to be performed for all unfinished transactions

•Log entry for writes:
[Write_item, T, X, Old_value,new_value)
•Undo operations are performed by reading the log in reverse order
•Log entries designed so that undo and redo operations are
idempotent.

Database Recovery Techniques 29

While a transaction runs:
 Changes made by the transaction can be written to the database at any time. Both original and the new data
being written, must be stored in the log before storing it on the disk.
On a commit:
 All the updates which has not yet been recorded on the disk is first stored in the log file and then flushed to disk.
 The new data is then recorded in the database itself.
 On an abort, redo all the changes which that transaction has made to the database disk using the log entries.
 On a system restart after a failure, redo committed changes from log.
General Idea:
1. Database is updated by transactions as and when they execute
2. Database updates are performed after the updates are recorded in the log and log is written onto disk
3. Undo all unfinished transactions since the last checkpoint
4. Redo all committed transactions since the last commit checkpoint
Recovery Techniques Based on Immediate Update …
Undo/Redo Algorithm (Single-user environment)
Recovery schemes of this category apply undo and also redo for recovery.

In a single-user environment no concurrency control is required but a log

is maintained under WAL.
Note that at any time there will be one transaction in the system and it will
be either in the commit table or in the active table.
The recovery manager performs:
• Undo of a transaction if it is in the active table.(Undo all the write_item
operations of the active transaction from the log)
• Redo of a transaction if it is in the commit table.
• (Redo the wri te_item operations of the committed transactions from the
log)

Slide 19- 31
Recovery in single environments
1.Use two lists of transactions :list of all committed transactions since the last checkpoint and list of all
active transactions since the last checkpoint
2.Undo the writes of all active transactions using the undo policy
3.Redo the wrote operations of all the committed transactions

Recovery in single environments

1.Use two lists of transactions :list of all committed transactions since the last checkpoint and list of all
active transactions since the last checkpoint
2.Undo the writes of all active transactions using the undo policy
3.Redo the wrote operations of all the committed transactions

Database Recovery Techniques 32

Recovery Techniques Based on Immediate Update
Undo/Redo Algorithm (Concurrent execution)
• Recovery schemes of this category applies undo and also redo to recover the database
from failure.
• In concurrent execution environment a concurrency control is required and log is
maintained under WAL.
• Commit table records transactions to be committed and active table records active
transactions.
• To minimize the work of the recovery manager checkpointing is used.
• The recovery performs:
• Undo of a transaction if it is in the active table.
• Redo of a transaction if it is in the commit table.

Slide 19- 33
Shadow paging recovery technique
Shadow paging considers the database to be made up of a number of fixed-size disk
pages (or disk blocks)
The AFIM(new data) does not overwrite its BFIM(old data) but recorded at
another place on the disk.
Thus, at any time a data item has AFIM (new )and BFIM(old) (Shadow copy of
the data item) at two different places on the disk.

X Y X and Y: Shadow copies of

X' Y' data items
X' and Y': Current copies
of data items
Database
Slide 19- 34
Shadow paging recovery technique…
• Maintain two directories during life of a transaction: current directory table(or current page
table) and shadow directory table(or shadow page table).
• A director has two columns: block sequence number and a pointer to a page in a disk.
• A directory with n entries' is constructed, where the ith entry points to the ith database page on
disk.
• Entries of the current directory point to the most recent or current database pages on disk
• When transaction starts, the two directories are the same.
• Store the shadow page table in nonvolatile storage
• Shadow directory is never changed thereafter and is used to restore database in event of failure.
i. e shadow page table is never modified during execution
• 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.
• When transaction completes, current directory becomes shadow directory. 35
Summary
Shadow paging considers:
1.The database is partitioned into fixed-length blocks referred to as PAGES.
2.Page table has n entries – one for each database page.
3.Each contain pointer to a page on disk (1 to 1st page on database and so on…).
•The idea is to maintain 2 pages tables during the life of transaction.
1.The current page table
2.The shadow page table
When transaction starts, both page tables are identical
1.The shadow page table is never changed over the duration of the transaction.
2.The current page table may be changed when a transaction performs a write operation.
3.All input and output operations use the current page table to locate database pages on disk.
Shadow Paging
• To manage access of data items by concurrent transactions two
directories (current and shadow) are used.
• The directory arrangement is illustrated below. Here a page
is a data item.

Slide 19- 37
To recover from a failure:
• The state of the database before transaction execution is available through the
shadow page table
• Free modified pages
• Discard current page table
• That state is recovered by reinstating the shadow page table to become the
current page table once mОre
• Committing a transaction
• Discard previous shadow page
• Free old page tables that it references
•To recover from a failure during transaction execution, it is sufficient to free the
modified database pages and to discard the current directory.
•Since recovery involves neither undoing nor redoing data items, this technique can
be categorized as a NO-UNDO/NO-REDO technique for recovery.
The ARIES Recovery Algorithm
• ARIES is a recovery algorithm that is designed to
work with a steal, no-force approach.
• Steal: if a frame is dirty and chosen for replacement,
the page it contains is written to disk even if the
modifying transaction is still active.
• No-force: Pages in the buffer pool that are modified by
a transaction are not forced to disk when the
transaction commits.

Slide 19- 39
The ARIES Recovery Algorithm’s main principles:
WAL (Write Ahead Logging): any change to DB element is first recorded in
log. The log record is written to stable storage before DB’s element change is
written to disk.
Repeating history during redo:
On restart following crash, retrace all actions of DBMS before
crash so system is back to the exact state it was at crash time.
Then undo (abort) transactions still active at time of crash.
Logging changes during undo:
Changes to DB while undoing a transaction are logged to ensure
such an action is not repeated in the event of repeated restarts
(from repeated failures).

Database Recovery Techniques 40

The ARIES Recovery Algorithm (contd.)
 After a crash, the recovery manager is invoked. The ARIES
recovery algorithm proceed in three phases:
1. Analysis: step identifies the dirty (updated) pages in the buffer
(I.e., changes not yet written to disk )and the set of
transactions active at the time of crash. The appropriate
point in the log where redo is to start is also determined.
2. Redo: repeats all actions, starting from proper point in
log, thus restoring the DB state to what it was at time of
crash.
3. Undo: log is scanned backwards and the operations of
transactions active at the time of crash are undone in reverse
order. (i.e. undo actions of transactions that didn’t
commit --> DB reflects only committed transactions).

Slide 19- 41
Example:
ANALYSIS:
LSN Log Record
T1, T3 active (-> undo)
10 - update: T1 writes P5 T2 committed (all its
20 --- update: T2 writes P3 actions therefore to be
30 - T2 commit written to disk)
40 --- T2 end P1, P2, P3 possibly dirty
50 - update: T3 writes P1
60 - update: T3 writes P3 REDO:
do updates 1, 2, 5, 6
X CRASH, RESTART UNDO:
undo 6, 5, 2
Execution History with a Crash

Database Recovery Techniques 42

ANALYSIS:
T1, T3 active (-> undo)
T2 committed (all its actions therefore to be written to
disk)
P1, P2, P3 possibly dirty
REDO:
order
All the updates (including those of T1 and T3) are reapplied in the
shown during the Redo phase.

UNDO: the actions of T1 and T3 are undone in reverse

order during the Undo phase; that is, T3's write of P3 is
undone, T3's write of P1 is undone, and then T1s write of P5
is undone.

Database Recovery Techniques 43

The ARIES Recovery Algorithm (contd.)
The Log and Log Sequence Number (LSN)
A log record is written for:
(a) data update: After modifying the page, an update type
record is appended to the log tail. The pageLSN of the
page is then set to the LSN of the update log record.
(b) transaction commit: When a transaction decides to
commit, it force-writes a commit type log record. That
is, the log record is appended to the log, and the log
tail is written to stable storage. Then , update any
DBMS data structures. Finally write commit log
record.)
In the case of undo a compensating log record is written.
The most recent portion of the log, called the log tail, is kept in
main memory and is periodically forced to stable storage.

Slide 19- 44
(c) transaction abort: When a transaction is aborted, an abort type log
record containing the transaction id is appended to the log and Undo
is initiated for this transaction
(d) transaction end: when a transaction is aborted or committed, some
additional actions must be taken beyond writing the abort or commit
log record such as removing the transaction's entry in the transaction
table. After all these additional steps are completed, an end type log
record containing the transaction id is appended to the log.

Database Recovery Techniques 45

(e) Undoing an update: When a transaction is rolled
back (because the transaction is aborted, or during
recovery from a crash), its updates are undone. When the
action described by an update log record is undone, a
compensation log record, or CLR, is written.

Database Recovery Techniques 46

The ARIES Recovery Algorithm (contd.)
The Log and Log Sequence Number (LSN) (contd.)
A unique LSN is associated with every log record.
LSN increases monotonically and indicates the disk
address of the log record it is associated with.
In addition, each data page stores the LSN of the
latest log record corresponding to a change for that
page.
A log record stores(Fields of log record):
1.Previous LSN of that transaction: It links the log record
of each transaction. It is like a back pointer points to the
previous record of the same transaction
2.Transaction ID :ID of transaction generating log rec.
3.Type of log record: commit, update, etc.

Slide 19- 47
ARIES update log record

• prevLSN
• transID
• type
• pageID // page id of modified page
• Length // length of change
• Offset // offset to change
• before-image // value before change
• after-image // value after change

• Redo-only update contains just after-image

• Undo-only update contains just before-image
OTHER data structures
• The Transaction table and the Dirty Page table
• Transaction Table: one entry for each active transaction:
• Tranaction Id
• Transaction Status // in progress, committed, aborted
// if C or A, will be eventually cleaned up.
• lastLSN //LSN of most recent log record for this transID
• Dirty Page table: One entry for each dirty page in the
buffer pool:
• recLSN // LSN of first log record that
caused page to be dirty. This is
the earliest log record that may
need to be redone during restart.
Slide 19- 49
Database Recovery
The ARIES Recovery Algorithm (contd.)
• Checkpointing
• A checkpointing does the following:
• Writes a begin_checkpoint record in the log
• Writes an end_checkpoint record in the log. With this record the contents of
transaction table and dirty page table are appended to the end of the log.
• Writes the LSN of the begin_checkpoint record to a special file. This special file is
accessed during recovery to locate the last checkpoint information.
• To reduce the cost of checkpointing and allow the system to continue to execute
transactions, ARIES uses “fuzzy checkpointing”.

Slide 19- 50
Database Recovery
The ARIES Recovery Algorithm (contd.)
• The following steps are performed for recovery
• Analysis phase: Start at the begin_checkpoint record and proceed to the end_checkpoint
record. Access transaction table and dirty page table are appended to the end of the log.
Note that during this phase some other log records may be written to the log and transaction
table may be modified. The analysis phase compiles the set of redo and undo to be
performed and ends.
• Redo phase: Starts from the point in the log up to where all dirty pages have been flushed,
and move forward to the end of the log. Any change that appears in the dirty page table is
redone.
• Undo phase: Starts from the end of the log and proceeds backward while performing
appropriate undo. For each undo it writes a compensating record in the log.
• The recovery completes at the end of undo phase.

Slide 19- 51
Database Recovery

Slide 19- 52