Recovery Control

• Database recovery is the process of restoring the database to a correct state

in the event of failure.
Master in Information • There are many different types of failure, each of which must be handled
Technology appropriately.
• Among the causes of failure are:
ICT - 209 – System crashes due to hardware or software errors.
– Media failures.
Database Applications – Natural disasters such as fire, flood, etc.
– Human error on the part of operators or users.
Error Recovery – Sabotage

• Whatever the cause of failure, there are two main effects that must be
considered:
– The loss of main memory, including database buffers
Slide 1 – The loss of the disk copy of the database. Slide 2

Transactions and Recovery Failure Example - I

• Transactions are the basic unit of recovery in a database system. • Consider the following example transaction from before:
• The recovery manager must guarantee two of the four ACID properties Read(Sno = x, Salary)
of transactions in the presence of failure:
Salary = Salary * 1.1
– Atomicity
Write(Sno = x, Salary)
– Durability
• For the Read operation, the DBMS performs the following steps:
• The recovery manager must ensure that, on recovery from failure, either
all of the effects of a transaction are permanently recorded in the – Find the address of the disk block containing the record with key value x.
database, or none of them are. – Transfer this disk block into a database buffer in main memory.
• The situation is complicated because the act of writing information to – Copy the salary data from the database buffer into the variable Salary.
the database is not an atomic action.
• For the Write operation, the following steps occur:
• Therefore, it is possible for a transaction to have committed, but for its
effects not to have been permanently recorded, simply because they – Find the address of the disk block containing the record with key value x.
have not yet reached the database.
– Transfer this disk block into a database buffer in main memory.
– Copy the salary data from the variable Salary into the database buffer.
Slide 3 – Write the database buffer back to disk. Slide 4

Failure Example - II Failure Example - III

• The database buffers function as an intermediate storage location (or • If the transaction that wrote prior to failure had issued its commit, then
cache) to minimise the cost of reading and writing data on disk. the recovery manager must redo the transaction’s updates to ensure
durability.
– So, it is common to delay writing them to disk until absolutely necessary.
– This is also known as roll-forward.
• It is only once the buffers have been flushed to disk that any update
operations can be regarded as permanent. • On the other hand, if the transaction had not committed at the time of
failure, then the recovery manager must undo any effects of that
• The flushing of buffers can be triggered by special commands (e.g., transaction to ensure atomicity.
transaction commit), or automatically when the buffer becomes full.
– This is also known as roll-back.
– Explicit flushing of the buffers is called force-writing.
• We will now consider another example to reinforce these ideas.
• Failure may occur between writing to the buffers and flushing the
buffers to disk.
– In this case, the recovery manager must determine the status of the
transaction that performed the write at the time of failure.

Slide 5 Slide 6

1
 Use of REDO/UNDO Use of UNDO/REDO
• Consider a number of concurrently executing transactions, T1…T6. • Clearly, T1 and T6 had not committed at the time of the crash.
• Therefore, at restart, the recovery manager must undo all changes made by T1
and T6.
T1 • However, it is not clear to what extent the changes made by the committed
T2 transactions have been propagated to the database on disk.

T3 • There is no way to know whether or not the volatile database buffers were
written (flushed) to disk before the crash occurred.
T4
• In the absence of any other information, the recovery manager is forced to redo
T5 (roll-forward) the (committed) transactions T2…T5: Why?
T6
– To ensure durability!
DBMS failure
starts occurs – however, see more, later, on this (use of checkpointing)!

Next: Recovery Facilities

Slide 7 Slide 8

Recovery Facilities Logging Facilities

• A DBMS should provide the following facilities to assist with recovery: • To keep track of database transactions, the DBMS maintains a special
file called a log.
– A backup mechanism, which makes periodic backup copies of the data.

– Logging facilities, which keep track of the current state of transactions and • The log contains information about all updates to the database.
database updates.
• The log primarily contains transaction records.
– A checkpoint facility, which enables updates to the database which are in
progress to be made permanent.
• A transaction record consists of:
– A transaction identifier.
– A recovery manager, which allows the system to restore the database to a
consistent state following a failure. – A record type (transaction start, insert, update, delete, abort, commit).
• The backup mechanism should allow the database and the log file to be – The identity of the affected data item (for insert, delete, and update).
archived at regular intervals without having to stop the system.
– Before-image of the data item (its value before an update or delete).
• The backup archive copies can be used to recover from severe failures – After-image of the data item (its value after an update or insert).
in which the storage media are damaged.
– Log management information.

Slide 9 Slide 10

Example of Log Contents Checkpointing-I

• Below is a segment of a log file showing three concurrent transactions
T1, T2, and T3. • The information in the log file is used to recover from a failure.
• To recover, we need to know from which point in the log we need to
Lid Tid Time Operation Object BI AI PPtr Nptr start undoing and redoing changes.
1 T1 10:12 START 0 2
2 T1 10:13 UPDATE STAFF SL21 (old) (new) 1 8 • The problem is that the log describes updates which have been made (to
3 T2 10:14 START 0 4 the buffers), but which have not necessarily been written to disk.
4 T2 10:16 INSERT STAFF SG37 (new) 3 5
5 T2 10:17 DELETE STAFF SA9 (old) 4 6
– i.e. they may still be in a buffer waiting to be flushed.
6 T2 10:17 UPDATE PROPERTY PG16 (old) (new) 5 10
7 T3 10:18 START 0 11
8 T1 10:18 COMMIT 2 0 • further information, we will needlessly end up redoing
Without
9 10:19 CHECKPOINT T2, T3 transactions that have been safely written to the disk.
10 T2 10:19 COMMIT 6 0
11 T3 10:20 INSERT PROPERTY PG4 (new) 7 12 • how much this has to be done, we use checkpointing.
To limit
12 T3 10:21 COMMIT 11 0
•
A checkpoint is a point of synchronisation between the database on
disk and the transaction log file
– At the time of a checkpoint, all buffers are force-written to disk.
Slide 11 Slide 12

2
 Checkpointing-II Use of REDO/UNDO with Checkpointing
• Checkpoints are scheduled at pre-determined intervals and involve the • Consider, again, the example from before:
following operations:
– Writing all log records in main memory out to disk. T1
T2
T3

transactions that are active at the time of the checkpoint (see previous T4
example)
T5
• When a crash occurs, the recovery manager examines the log file for the T6
last checkpoint record.
DBMS failure
– All transactions that have committed since (i.e. after) the last checkpoint are checkpoint
starts occurs
• When failure occurs, we can assume that T2 and T3 are permanently recorded
redone
– Any transactions active at the time of the crash are undone. • However, T1 and T6 must be undone (since they were active at the time of the
• Since checkpoints are relatively inexpensive, it is often possible to take crash), and T4 and T5 must be redone (since they committed after the
checkpoint i.e. their updates will not have reached the disk).
3 or 4 per hour
– This way, no more than 15-20 minutes work is lost. Slide 13 Slide 14

Recovery Techniques Deferred Update

• The recovery manager must be able to restore a database to a consistent • Using this technique, updates are not written to the database until after a
state after a crash has occurred. transaction has reached its commit point.
• We assume that the database is not physically damaged, just • Thus, if a transaction fails before the commit point, it will not have
inconsistent. modified the database (its updates will not have reached the database
buffer or disk).
– For a damaged database, the backup archives must be used.
– Therefore, no changes need to be undone.
• To restore consistency, the recovery manager must process the before-
and after-images held in the log to undo and redo the changes which • However, it may be necessary to redo the updates of transactions which
have caused the inconsistency. committed after the checkpoint as their effect may not have been written
to the database on disk at the time of a crash.
• We will now examine two different recovery techniques.
• The way in which the log is used is described next...
– Deferred update

– Immediate update

Slide 15 Slide 16

Deferred Update Log Usage Immediate Update

• When a crash occurs, the log is examined to see which transactions were • Using this technique, updates are applied to the database at the same time
active at the time of the failure. as they occur.
• Starting at the last log record, we go back to the last checkpoint. – It is not necessary to wait until the commit point is reached.
– Any transaction with both START and COMMIT records should be redone
(since it committed after the checkpoint, and not ‘all’ its updates will have • We still have to redo the updates of committed transactions following a
reached the disk). failure (i.e. those transactions which committed ‘after’ the last
checkpoint).
– The redo procedure applies the after-image log records to the database on
disk in the original order in which they were written to the log.
• However, it may now be necessary to undo the effects of transactions
– Any transaction with START and ABORT records is ignored, since no that had not committed at the time of failure - since their (immediate)
database updates need to be redone or undone (hence, the before-image is updates will have reached the buffers, and subsequently the disk (at
not required for deferred update).
checkpoint).
• Note that further system crashes do not affect recovery
• The way in which the log is used is described next...
– It does no harm to redo database updates more than once.

Slide 17 Slide 18

3
 Immediate Update Log Usage
• If a transaction aborts, the log can be used to undo it using the saved before-
images.
– Since a transaction may change an item several times, the changes made by an aborted transaction
are undone in reverse order.
– This guarantees that the database is restored to the state before the transaction started.

• On failure, recovery involves using the log to undo or redo transactions.

– Transactions with both START and COMMIT records are redone (since the transaction has
committed after the last checkpoint), using the after-image information in the log (redo is performed
in log order).
– Transactions with a START but no COMMIT record (i.e. active at time of crash) are undone using
the before-image information (undo is performed in reverse log order).

• See/practice Tutorial questions on this topic

• If interested(!) - you can read more about details of the actual log
operations for Deferred Update and Immediate Updates, in Textbook
(Connolly & Begg, Sec. 17.3)

Slide 19