Department of Computer Science & Engineering

CS3CO39 DBMS
Session: Jan-Jun 2021

Transaction Processing System

Presented By:
Trishna Panse
Prepared by: Trishna Panse, Asst. Asst. Prof., CSE 1
Professor, CSE
Unit-4
Database Transactions Processing: Introduction to Transaction Processing,
Transaction Concepts, Desirable Properties of Transactions, Schedules,
Concepts of Recoverability and Serializability, Concurrency control:
introduction, locking protocols.

Prepared by: Trishna Panse, Asst. Professor, CSE

What is Transaction?
• A transaction is a single logical unit of work which accesses and
possibly modifies the contents of a database.
• Transactions access data using read and write operations.
• In order to maintain consistency in a database, before and after the
transaction, certain properties are followed. These are called ACID properties.

Prepared by: Trishna Panse, Asst. Professor, CSE

Transaction ACID Properties:
Atomicity
• By this, we mean that either the entire transaction takes place at once or doesn’t happen
at all. There is no midway i.e. transactions do not occur partially.

• It involves the following two operations.

—Abort: If a transaction aborts, changes made to database are not visible.
—Commit: If a transaction commits, changes made are visible.

• Atomicity is also known as the ‘All or nothing rule’.

Consider the following transaction T consisting of T1 and T2: Transfer of 100 from
account X to account Y.

If the transaction fails after completion of T1

but before completion of T2.
( say, after write(X) but before write(Y)),
then amount has been deducted from X but
not added to Y. This results in an
inconsistent database state.
Prepared by: Trishna Panse, Asst.
Professor, CSE
Transaction ACID Properties:
Consistency:
• This means that integrity constraints must be maintained so that the database is
consistent before and after the transaction. It refers to the correctness of a database.

Isolation:
• This property ensures that multiple transactions can occur concurrently without leading
to the inconsistency of database state.
• Changes occurring in a particular transaction will not be visible to any other transaction
until that particular change in that transaction has been committed.

Durability:
• This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a
system failure occurs.
• These updates now become permanent and are stored in non-volatile memory.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Transaction States in DBMS
• States through which a transaction goes during its lifetime.
• These states specify about the current state of the Transaction and also specify that how
we will process the transactions.
• These states govern the rules which decide that whether a transaction will commit or
abort.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Transaction States in DBMS
• Active State –When the instructions of the transaction is running then the transaction is
in active state.

• Partially Committed –After completion of all the read and write operation the changes
are made in main memory or local buffer. If the changes are made permanent on the Data
Base then state will change to “committed state” and in case of failure it will go to “failed
state”.

• Failed State –When any instruction of the transaction fails it goes to “failed state”.

• Aborted State –After having any type of failure the transaction goes from “failed state”
to “aborted state” and in before states the changes are only made to local buffer or main
memory and hence these changes are deleted or rollback.

• Committed Stage –It is the stage when the changes are made permanent on the Data
Base and transaction is complete and therefore terminated in “terminated state”.

• Terminated State –If there is any roll back or the transaction come from “committed
state” then the system is consistent and ready for new transaction and the old transaction
is terminated. Prepared by: Trishna Panse, Asst.
Professor, CSE
Types of Schedules

Prepared by: Trishna Panse, Asst.

Professor, CSE
Serial Schedules:
• A serial schedule is one in which no transaction starts until a running transaction has
ended are called serial schedules.
• For example, if T1 and T2 are two transactions in a schedule then either T1 is followed
by T2 or T2 is followed by T1 then it is called Serial Schedule.
• Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2
R(A)
A B
A=A-50
2000 2000
W(A) 1950 2050
R(B) 1850 2150
B=B+50
W(B)
T1 T2
R(A)
A B A B
A=A-100
2000 2000 1950 2050
W(A)
1950 2050 1850 2150
R(B)
B=B+100
W(B)

Prepared by: Trishna Panse, Asst.

Professor, CSE
Concurrent Schedules in DBMS
• This is a type of Scheduling where the operations of multiple transactions are
interleaved.
• Means there are no sequences among the operations of T1 & T2 i.e. sometimes T1 is
followed by T2 or sometimes T2 is followed by T1 randomly then it is called
Concurrent Transactions.
• This might lead to a rise in the concurrency problem and concurrency always leads to
inconsistency.
• Unlike the serial schedule where one transaction must wait for another to complete all its
operation, in the non-serial schedule, the other transaction proceeds without waiting for
the previous transaction to complete.
• It can be of two types namely, Serializable and Non-Serializable Schedule.

Prepared by: Trishna Panse, Asst.

Professor, CSE
 Concurrent Schedules in DBMS
T1 T2 T1 T2

R(A) R(A)

A=A-50 A=A-50
R(A)
W(A)
A=A-100
R(A) Serializabl
e W(A)
A=A-100
Concurren W(A)
W(A)
t Schedule R(B)
R(B)
B=B+50
B=B+50 Non
Serializabl W(B)
W(B)
e R(B)
R(B)
Concurrent
B=B+100 B=B+100
Schedule
W(B)
W(B)

A B A B
2000 2000 2000 2000
1950 2050 1900 2050
1850 2150 1950 2150

T2 T1 T2
T1
A B A B A B
A B
1950 2050 2000 2000 2000 2050
2000 2000
1850 2150 2050 1900 2150
19 2050
50
Serializable Concurrent Schedules
The Non-Serial Schedule can be divided further into Serializable and Non-Serializable.
Serializable:
• The non-serial schedule is said to be in a serializable schedule only when it is equivalent
to the serial schedules.
• This is used to maintain the consistency of the database. It is mainly used in the Non-
Serial scheduling to verify whether the scheduling will lead to any inconsistency or not.
• A serializable schedule helps in improving both resource utilization and CPU
throughput.

These are of two types:

• Conflict Serializable: A schedule is called conflict serializable if it can be transformed
into a serial schedule by swapping non-conflicting operations.

• View Serializable: A Schedule is called view serializable if it is view equal to a serial

schedule (no overlapping transactions).

Prepared by: Trishna Panse, Asst.

Professor, CSE
Non Serializable Concurrent Schedules
Recoverable Schedule:

T1 T2
R(X)
X=X-100
W(X)
R(X)
X=X+50
W(X)
Commit
Commit

This is a recoverable schedule since T1 commits before T2, that makes the value read by
T2 correct.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Non Serializable Concurrent Schedules
Irrecoverable Schedule:

T1 T2
R(X)
X=X-100
W(X)
R(X)
X=X+50
W(X)
Commit

(Fail)

T2 read the value of A written by T1, and committed. T1 later aborted, therefore the
value read by T2 is wrong, but since T2 committed, this schedule is non-recoverable.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Conflict Serializability in DBMS
• As discussed that serial schedules have less resource utilization and low throughput.
• To improve it, two or more transactions are run concurrently. But concurrency of
transactions may lead to inconsistency in database.
• To avoid this, we need to check whether these concurrent schedules are serializable or
not. For this, we have two methods:
– 1. Conflict Serializability
– 2. View Serializability

Conflict Serializable: A schedule is called conflict serializable if it can be transformed into a

serial schedule by swapping non-conflicting operations.

Conflicting operations: Two operations are said to be conflicting if all conditions satisfy:

• They belong to different transactions

• They operate on the same data item
• At Least one of them is a write operation

Prepared by: Trishna Panse, Asst.

Professor, CSE
Conflict Serializability
• If a schedule S can be transformed into a schedule S´ by swapping of non-conflicting
instructions, we say that S and S´ are conflict equivalent.
• We say that a schedule S is conflict serializable if it is conflict equivalent to a serial
schedule.
Schedule S Schedule S`

• Schedule S can be transformed into Schedule S`, a serial schedule where T2 follows T1,
by series of swaps of non-conflicting instructions. Therefore Schedule S is conflict
serializable.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Conflict Serializability
• Example of a schedule that is not
conflict serializable:

• We are unable to swap instructions in the above schedule to obtain either

the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Testing conflict serializability of a schedule

1. For each transaction Ti participating in schedule S, create a node in graph.

2. For each case where Ti Write(X) then Tj Read(X) , create an edge from Ti to Tj

3. For each case, where Ti Read(X) then Tj Write(X) , create an edge from Ti to Tj

4. For each case, where Ti Write(X) then Tj Write(X) , create an edge from Ti to Tj

5. The schedule S is serializable, if and only if there is no cycle in graph.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Testing conflict serializability of a schedule

T1 T2
R(X) T1 executes W(X) after T2
X=X-50 executes R(X), then edge T2->T1
R(X)
X=X-100
W(X)
R(Y)
T1 T2
W(X)
Y=Y+50
W(Y)
T2 executes W(X) after T1
executes W(X), then edge T1->T2
Cycle is created in graph, so given schedule is non serializable concurrent
schedule.

Hence we can not convert it into equivalent serial schedule.

Prepared by: Trishna Panse, Asst.

Professor, CSE
Testing conflict serializability of a schedule

T1 T2 Step1- First, remove all statements except R & W

R(X)
T1 Can not be
X=X-50
interchanged, since
R(X) T2
R(X) and W(X) are not
X=X-100 R(X) compatible
W(X) R(X)

R(Y) W(X)
R(Y) Can not be
W(X)
interchanged, since
Y=Y+50 W(X)
W(X) and W(X)
W(Y) W(Y) are not compatible

Step2- Try to convert this given schedule into its equivalent serial schedule by swapping
all instructions of a transactions at one place.

Step3- Since, operations can not be interchanged, so given schedule is non serializable
concurrent schedule.

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability:
• A schedule will be view serializable if it is view equivalent to a
serial schedule.
• If a schedule is conflict serializable, then it will be view serializable.

View Equivalent-
• Two schedules S1 and S2 are said to be view equivalent if they satisfy the
following 3 conditions:

1. Initial Read (First Read)

2. Final Write (Last Write)
3. Updated Read

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability Cont.…:
1. Initial Read
• An initial read of both schedules must be the same.
• Suppose two schedule S1 and S2. In schedule S1, if a transaction T1 is
reading
the data item A, then in S2, transaction T1 should also read A.

• Above two schedules are view equivalent because Initial read operation in S1 is
done by T1 and in S2 it is also done by T1.

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability Cont.…:
2. Final Write
• A final write must be the same between both the schedules.
• In schedule S1, if a transaction T1 updates A at last then in S2, final
writes operations should also be done by T1.

• Above two schedules is view equal because Final write operation in S1 is done
by T3 and in S2, the final write operation is also done by T3.

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability Cont.…:
3. Updated Read
• In schedule S1, if Ti is reading A which is updated by Tj then in S2
also,
Ti
should read A which is updated by Tj.

• Above two schedules are not view equal because, in S1, T3 is reading
A
updated by T2 and in S2, T3 is reading A updated by T1.

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability Example 1:
Consider a schedule S, check whether it is view equivalent or not-

Schedule S

• First convert it into its equivalent schedule S1

Schedule S1

Prepared by: Trishna Panse, Asst.

Professor, CSE
View Serializability Example 1 cont.…:
Schedule S Schedule S1

Step 1: Initial Read

• The initial read operation in S is done by T1 and in S1, it is also done by T1.

Step 2: Final Write

• The final write operation in S is done by T3 and in S1, it is also done by T3. So, S and S1
are view Equivalent.

Step 3: Final update on data items

• In both schedules S and S1, there is no read except the initial read that's why we don't
need to check that condition.

The schedule S1 satisfies all 3 conditions. Hence, view equivalent serial schedule is:
T1 → T2 → T3
Prepared by: Trishna Panse, Asst.
Professor, CSE
 Outline

Concurrency Control Techniques

■ Lock-Based Protocols
■ Timestamp-Based Protocols
■ Validation-Based Protocols

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Lock-Based Protocols
■ A lock is a mechanism to control concurrent access to a data item

■ Data items can be locked in two modes :

1. exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is
requested using lock-S instruction.

■ Lock requests are made to the concurrency-control manager by the

programmer. Transaction can proceed only after request is granted.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Lock-Based Protocols (Cont.)
■ Lock-compatibility matrix

■ A transaction may be granted a lock on an item if the requested lock

is compatible with locks already held on the item by other
transactions
■ Any number of transactions can hold shared locks on an item,
● But if any transaction holds an exclusive on the item no other
transaction may hold any lock on the item.
■ If a lock cannot be granted, the requesting transaction is made to wait
till all incompatible locks have been released.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 The Two-Phase Locking Protocol

read_lock(x)
B: if lock(x)=“unlocked”
then, lock(x)= “readlock”
no_of_reads(x) 1 end;

else if lock(x)= “readlock”

then, no_of_reads(x) no_of_reads(x) +1
end;

else
wait (until lock(x)=“unlocked”) and lock manager wakeup
transaction
goto B;
end;

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 The Two-Phase Locking Protocol

write_lock(x)
B: if lock(x)=“unlocked”
then, lock(x)= “writelock”
end;
else
wait (until lock(x)=“unlocked”) and lock manager wakeup
transaction
goto B;
end;

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 The Two-Phase Locking Protocol

unlock(x)
B: if lock(x)=“writelock”
then, lock(x)= “unlocked”
end;
else if lock(x)= “readlock”
then, no_of_reads(x) no_of_reads(x) -1
if (no_of_reads(x) =0)

then lock(x)= “unlocked”

wakeup one of the waiting transaction, if any
end;

end;

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 The Two-Phase Locking Protocol

■ This protocol ensures conflict-serializable schedules.

■ Phase 1: Growing Phase

● In this phase a transaction can only acquire locks but cannot
release any lock.

■ Phase 2: Shrinking Phase

● Transaction may release locks
● Transaction may not obtain locks

■ The protocol assures serializability.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 The Two-Phase Locking Protocol

■ Problems in 2 phase locking

■ Advantage- Always ensures serializability

■ Disadvantages-
● Not free from deadlock
● Not free from cascading rollback
● May not free from irrecoverable schedule

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Deadlocks
■ Consider the partial schedule

■ Neither T3 nor T4 can make progress — executing lock-S(B) causes

T4 to wait for T3 to release its lock on B, while executing lock-X(A)
causes T3 to wait for T4 to release its lock on A.
■ Such a situation is called a deadlock.
● To handle a deadlock one of T3 or T4 must be rolled back and
its locks released.
Prepared by: Trishna Panse, Asst.
P rtoh f e s s o r, CSE
Strict & Rigorous two-phase locking
■ To avoid this, a modified protocol called strict two-phase
locking -- a transaction must hold all its exclusive locks till it
commits/aborts.

■ Rigorous two-phase locking is even stricter. Here, all

locks are held till commit/abort. In this protocol transactions can
be serialized in the order in which they commit.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Timestamp-Based Protocols
■ Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-
stamp TS(Tj) such that TS(Ti) <TS(Tj).
■ The protocol manages concurrent execution such that the time-stamps
determine the serializability order.
■ In order to assure such behavior, the protocol maintains for each data
Q two timestamp values:
● W-timestamp(Q) is the largest time-stamp of any transaction that
executed write(Q) successfully.
● R-timestamp(Q) is the largest time-stamp of any transaction that
executed read(Q) successfully.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Timestamp-Based Protocols (Cont.)
■ Suppose a transaction Ti issues a read(Q)
1. If TS(Ti) ≤ W-timestamp(Q), then Ti needs to read a value of Q
that was already overwritten.
■ Hence, the read operation is rejected, and Ti is rolled back
because some another younger transaction is
having large timestamp than Ti. .
2. If TS(Ti) ≥ W-timestamp(Q), then the read operation is executed,
and R-timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Timestamp-Based Protocols (Cont.)
■ Suppose that transaction Ti issues write(Q).
1. If TS(Ti) < R-timestamp(Q), then Ti is aborted and rollbacked
because some another younger transaction is having large
timestamp than Ti.
■ Hence, the write operation is rejected, and Ti is rolled back.

2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an

obsolete(old) value of Q.
■ Hence, this write operation is rejected, and Ti is rolled back.

3. Otherwise, the write operation is executed, and W-timestamp(Q) is set

to TS(Ti).

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Validation-Based Protocol
■ Also called certification method.
■ No checking is done while transaction is executing.
■ Means updates are not directly applied to the database until transaction
reaches to its end.
■ During the transaction, all the updates are applied to a local copy of
database.
■ At the end of the transaction, a validation phase checks whether any of the
transaction updates violates serializability or not.
■ If it is not violated then transaction is committed otherwise it is aborted.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Validation-Based Protocol
■ Execution of transaction Ti is done in three phases.
1. Read and execution phase: Transaction Ti writes only
to temporary local variables
2. Validation phase: Transaction Ti performs a ''validation test'' to
determine if local variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise, Ti is rolled back.

■ The three phases of concurrently executing transactions can be interleaved,

but each transaction must go through the three phases in that order.

■ Also called as optimistic concurrency control since transaction

executes fully in the hope that all will go well during validation

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
Transaction Recovery

• Recovery means that the database is restored to the most recent

consistent state just before the time of failure.
• A non-serializable schedule is not guaranteed to produce the same effect
as produced by some serial schedule on any consistent database.

Characteristics of Non-serializable schedules-

■ may or may not be consistent- Conflict & View Serializability
■ may or may not be recoverable

A Concurrent Schedule may be-

-Recoverable Schedule
-Irrecoverable Schedule

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Irrecoverable Schedule:
• A transaction performs a dirty read operation from an uncommitted
transaction and commits before the transaction from which it has read
the value then such a schedule is known as an Irrecoverable Schedule.

T1 T2
R(X)
X=X-100
W(X)
R(X)
X=X+50
W(X)
Commit

(Fail)

PrepPare repdparbaeyrde: d a n d c o
P re
Database System Concepts - 6th Edition 15.43 Bhupendr
m pPrP
©Silberschatz, a
Korth l eass
and
i ofe norbc, ChSEal , A ss
dSudarshan
Recoverable Schedule:
• A transaction performs a dirty read operation from an uncommitted
transaction and its commit operation is delayed till the uncommitted
transaction either commits or roll backs then such a schedule is known as
a Recoverable Schedule.
T1 T2
R(X)
X=X-100
W(X)
R(X)
X=X+50
W(X)
Commit
Commit

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
Checking Whether a Schedule is Recoverable or Irrecoverable-

Method-01:

• Check whether the given schedule is conflict serializable or not.

• If the given schedule is conflict serializable, then it is surely
recoverable. Stop and report your answer.
• If the given schedule is not conflict serializable, then it may or may not
be recoverable. Go and check using other methods.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Checking Whether a Schedule is Recoverable or Irrecoverable-

Method-02:
Check if there exists any dirty read operation.

• If there is no any dirty read operation, then the schedule is

surely recoverable. Stop and report your answer.
• If there exists any dirty read operation, then the schedule may or may
not be recoverable.

Case-01:
• If the commit operation of the transaction
performing the dirty read occurs before the commit
or abort operation of the transaction which
updated the value, then the schedule is
irrecoverable.
Case-02: PrePpraerpeadrebdy:aTnrdischonm
ConceptsPa-P6nrcEdition
©Silberschatz, Korth and Sudarshan15.46Database SystemBhupendra o hfaels, sAosrs, tC.
Types of Recoverable Schedules-

A recoverable schedule may be any one of these kinds-

1. Cascading Schedule
2. Cascade less Schedule
3. Strict Schedule

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Types of Recoverable Schedules-

1. Cascading Schedule
• If in a schedule, failure of one transaction causes
several other dependent transactions to rollback or
abort, then such a schedule is called as a Cascading
Schedule or Casc a
ding Rollback or Cascading
In this sch e d u le ,
• ofI transaction
• The failure t s i mT1 ply leadsbort.
toA
causes the transaction T2 to
rollback. the wastage of CPU time.
• The rollback of transaction T2
causes the transaction T3 to
rollback.

• The rollback of transaction T3

causes the transaction T4 to
rollback.

Such a rollback is called as a

Cascading Rollback.
Prepared by: Trishna Panse, Asst.
P rtoh f e s s o r, CSE
 Types of Recoverable Schedules-

2. Cascade less Schedule

• If in a schedule, a transaction is not allowed to read
a data item until the last transaction that has
written it is committed or aborted, then
such a schedule is called ashedule.
a Cascade less Sc
Howev
write er,
operations.
• n ly
operations and save CPU t committed
it all o w s u nc om m itt e d
I n o t h e r w o rd s , it read ime.

allows o

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
Types of Recoverable Schedules-

3. Strict Schedule
• If in a schedule, a transaction is neither allowed
to read nor write a data item until the last
transaction is committed or aborted, then such a
hedule.trictasSc
schedule is called aS
• In other word
s, Strict nly schedule
committed re
allows o ad and
write operations.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Failure Classification
■ Transaction failure :
● Logical errors: transaction cannot complete due to some internal error
condition
● System errors: the database system must terminate an active transaction due to
an error condition (e.g., deadlock)

■ System crash: a power failure or other hardware or software failure causes the
system to crash.

■ Disk failure: disk failure destroys all or part of disk storage

■ Physical Problems: including fire, power failure, theft, overwriting disks/taps etc.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Database Recovery Concepts
■ Recovery means that the database is restored to the most recent consistent state just
before the time of failure.

■ For this, system keeps update information that are made to database into a system
log.

■ System log contains information about start and end of each transaction and any updates
which occur in the transaction.

■ This information is needed to recover from transaction failure.

● If a system is physically damaged such as disk crash, then a past copy

of database is restored.
● If system becomes inconsistent due to other failure then reverse the
changes by undoing operations.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Undo and Redo Operations
■ Undo of a log record <Ti, X, V1, V2> writes the old value V1 to
X
● undo(Ti) restores the value of all data items updated by Ti to their old
values, going backwards from the last log record for Ti

■ Redo of a log record <Ti, X,V1, V2> writes the new value V2 to X
● redo(Ti) sets the value of all data items updated by Ti to the new
values, going forward from the first log record for Ti

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Database Recovery
Techniques
1. Undoing –
■ If a transaction crashes, then the recovery manager may undo transactions i.e. reverse
the operations of a transaction.

■ This involves examining a transaction for the log entry write_item (T, X, V1, V2) and
setting the value of item x in the database to old-value.

There are two major techniques for recovery from transaction failures:
■ Deferred update
■ Immediate update

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Deferred Update
■ This technique does not physically update the database on disk until a
transaction has reached its commit point.

■ Before reaching commit, all transaction updates are recorded in the local
transaction workspace.

■ If a transaction fails before reaching its commit point, it will not have
changed the database in any way so UNDO is not needed.

■ If a transaction reaches to its commit point then it is necessary to REDO

the effect of the operations that are recorded in the local transaction
workspace, because their effect may not yet have been written in the
database.

■ Hence, a deferred update is also known as the No-undo/Redo

algorithm

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
 Immediate Update
■ In the immediate update, the database may be updated by some
operations of a transaction before the transaction reaches its commit
point.

■ However, these operations are recorded in a log on disk before they are applied
to the database, making recovery still possible.

■ If a transaction fails to reach its commit point, the effect of its operation must
be undone i.e. the transaction must be rolled back hence we require both
undo and redo.

■ This technique is known as undo/redo algorithm.

Prepared by: Trishna Panse, Asst.

P rtoh f e s s o r, CSE
Thank You

Prepared by: Trishna Panse, Asst. 57

Professor, CSE