Database Recovery Management

Whenever a transaction is submitted to a DBMS

for execution, the system is responsible for
making sure that:
• All the operations in the transactions are
completed successfully and their effect is
recorded permanently in the database.
• The transaction has no effect whatsoever on
the database or any other transactions
 Database Recovery Management

The DBMS must not permit some operations of

a transaction T to be applied to the database
while other operations of T are not. However
this may happen if a transaction fails after
executing some of its operations but before
executing all of them. Such fails could be due
to:
 Database Recovery Management

• System crash
• Transaction error
• Errors detected by the transaction ( lack of data
required)
• Concurrency control enforcement (Violation of
rules)
• Disk failure
• Physical problems and catastrophes- fire, theft,
overwriting by mistake
 Transaction and System Concepts

A transaction is an atomic unit of work that is

either completed in its entirety or not done at
all. For recovery purposes the system needs to
keep track of when the transaction starts,
terminates and commits or aborts. The recovery
manager keeps track of the following operations:
• BEGIN_TRANSATION
• READ or WRITE
• END_TRANSATION
 Transaction and System Concepts for
recovery
At this point it may be necessary to check
whether the changes introduced by the
transaction can be permanently applied to the
database (committed) or whether the
transaction has to be aborted because it
violates concurrency control or for some other
reason.
 Transaction and System Concepts for
recovery
COMMIT_TRANSACTION: successfully end, updates
commited to the database and will not be undone
ROLLBACK (or ABORT): unsuccessful, effects of
transaction must be undone
UNDO: similar to rollback except applies to a single
operation than a whole transaction
REDO: specifies that certain transaction operations
must be redone.
State transition diagram
 THE SYSTEM LOG

To be able to recover from transaction failures,

the system maintains a log (journal). It keeps
track of all operations that affect the values of
database items. This information may be
needed to permit recovery from transaction
failures
 THE SYSTEM LOG
[start_ Transaction, T]
[write_item, T, X, old_value, new_value]
[read_item, T, X]
[Commit,T]
[abort, T]
 THE SYSTEM LOG
The above statements are examples of what the log
would keep. Because the log contains a record of
every WRITE operation that changes the value of
some database item, it is possible to UNDO( similar
to ROLLBACK except applies to a single operation
rather than a whole transaction) and REDO
( specifies that certain transaction operations must
be redone) the effect of these WRITE operations of
a transaction by tracing backward or forward
respectively.
 Commit Point of A Transaction
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 transactions operations on the
database has been recorded in the log.
Beyond the commit point the transaction is
said to be commited and its effect is assumed
to be permanently recorded in the database.
 Commit Point of A Transaction
The transaction then writes an entry
[COMMIT,T] into the log. If a system failure
occurs, we search back in the log for all
transactions T that have a [START_Transaction,
T] entry into the log but have not written their
[COMMIT, T] entry yet-their effects can be
undone. Those that have their commit entries
can be redone from the log entries.
 Schedules and Recoverability
When transactions are executing concurrently in
an interleaved fashion, the order of execution
of operations from the various transactions
form what is known as a transaction schedule
(or history).
 Schedules and Recoverability
Consider schedules for the lost update problem and the
dirty read problem:

Sa: r1(X); r2(X); w1(X); r1 (Y); w2(X); C2 ; w1(Y); C1; (T2 is not
reading after T1 has updated)

Sb: r1(X); w1(X); r2(X); w2(X); C2; r1(Y); a1; ( we assume that
transaction T1 aborted after its read item (Y) operation)
 Schedules and Recoverability
Two operations in a schedule are said to conflict
if they belong to different transactions, if they
access the same data item X and if one of the
two operations is a write_item (X).
A schedule S of n transactions T1, T2......Tn is
said to be a correct schedule if the following
conditions hold:
 Schedules and Recoverability
• The operations in S are exactly those operations
in T1, T2....Tn, including a commit or abort
operation as the last operation for each
transaction in the schedule.
• For any pair of operations from the same
transaction Ti, their order of appearance in S is
the same as their order of appearance in Ti
• For any two conflicting operations one of the
two must occur before the other in the schedule.
 Characterizing Schedules based on
Recoverability
Once a transaction T is committed, it should
never be necessary to rollback T. The
schedules that meet this criterion are called
recoverable schedules.
A schedule S is said to be recoverable if no
transaction T in S commits until all
transactions T’ that have written an item that
T reads have committed.
 Characterizing Schedules based on
Recoverability
A transaction T is said to read from transaction
T’ in a schedule S if some item X is first written
by T’ and later read by T.
In the schedule S, T’ should not have aborted
before T reads item X, and there should be no
transactions that write X after T’ writes it and
before T reads it.
 Characterizing Schedules based on
Recoverability
Sa is recoverable. But consider Sc
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); C2; a1;

Sc is not recoverable because T2 reads item X from T1, and

then T2 commits before T1 commits. If T1 aborts after the
C2 operation in Sc, then the value of X that T2 read is no
longer valid and T2 must be aborted after it had already
committed, leading to a schedule that is not recoverable.
For the schedule to be recoverable, the C2 operation in Sc
must be postponed until after T1 commits.
 Serializability of Schedules:
A schedule S is serial if for every transaction T
participating in the schedule, all the operations of T are
executed consecutively in the schedule; otherwise the
schedule is called non-serial. Every serial schedule is
considered correct, as long as every transaction is
executed from beginning to end without any
interference from the operations of other transactions,
we get a correct end result on the database. The
problem with serial schedules is that they limit
concurrency or interleaving of operations.
 Serializability of Schedules
In a serial schedule, if a transaction waits for I/O
operation to complete we cannot switch the CPU
processing time to another transaction thus wasting it
and making serial schedules generally unacceptable.

To determine which of the non-serial schedules always

give a correct result and which may give an erroneous
result, the concept of the serializability of a schedule
is used.
 Serializability of Schedules
A schedule S of n transactions is serializable if its
equivalent to some serial schedule of the
same n transactions. Saying that a non-serial
schedule is serializable is equivalent to saying
it is correct. For two schedules to be
equivalent, the operations applied to each
data item affected by the schedules should be
applied to that that item in both schedules in
the same order.
 Serializability of Schedules
Two definitions of equivalence of schedules are
generally accepted:
• Conflict equivalence
• View equivalence
 Serializability of Schedules
Two schedules are said to be conflict equivalent
if the order of any two conflicting operations is
the same in both schedules.
Using the notion of conflict equivalence, we
define a schedule S to be conflict serializable if
it is (conflict) equivalent to some serial
schedule S’, in such a case we can reorder the
non-conflicting operations in S until we form
the equivalent serial schedule S.
 Serializability of Schedules
In practice the theory of serializability is used to
set up protocols/rules which if followed by
every individual transaction or if enforced by a
DBMS concurrency control subsystem, ensure
serializability of all schedules in which the
transactions participate
 Serializability of Schedules
View equivalence on the other hand holds that
as long as each read operation of a transaction
reads the result of the same write operation in
both schedules, the write operations of each
transaction must produce the same results.
 Testing for Serializability of a schedule S

1. For each transaction Ti participating in the

schedule S, create a node labeled Ti in the
precedence graph.
2. For each case in S where Tj executes a read_item
(X) after Ti executes a write_item(X), create an edge
Ti Tj in the precedence graph
3. For each case in S where Tj executes a write_item(X)
after Ti executes a read_item(x), create an edge Ti
Tj in the precedence graph
 Testing for Serializability of a schedule S

4. For each case in S where Tj executes a

write_item(X) after Ti executes a
write_item(X), create an edge (Ti Tj ) in the
precedence graph.
5. The schedule S is serializable if and only if the
precedence graph has no cycles.
Testing for Serializability
Testing for Serializability
Testing for Serializability
Testing for Serializability
Testing for Serializability