DBMS

DATA BASE MANAGEMENT SYSTYEMS

Module -- 5
Transaction Processing, Concurrency Control,
and Recovery
 DBMS - Transaction

• A transaction can be defined as a group of

tasks.
• It is a sequence of one or more database operations that are
grouped together as a single, indivisible, and atomic unit of work.
• A transaction can include operations such as reading data from
the database, modifying data in the database, or both.
• The main purpose of a transaction is to ensure the
consistency,
reliability, and
durability of the database.
 DBMS - Transaction
• In order to maintain these properties, DBMS provides the
ACID properties (Atomicity, Consistency, Isolation, and
Durability) for transactions.
• A single task is the minimum processing
unit that cannot be divided further.
 Example
Let’s take an example of a simple transaction.

Suppose a bank employee transfers Rs 500 from A's account to

B's account.

This very simple and small transaction involves several low-level

tasks.
A’s Account B’s Account
Open_Account(A) Open_Account(B)
Old_Balance = A.balance Old_Bal = B.bal
New_Balance = Old_Balance–500 New_Bal = Old_Bal + 500
A.balance = New_Balance B.bal = New_Bal
Close_Account(A) Close_Account(B)
 States of Transactions

A transaction in a database can be in one of the following states

 Active state
• This is the first state in the life cycle of a transaction.
• Once the transaction starts executing, then it is said to be in
active state.
• During this state it performs operations like READ and WRITE
on some data items. All the changes made by the transaction
are now stored in the buffer in main memory. They are not
updated in database.
• From active state, a transaction can go into either a partially
committed state or a failed state.
 Partially Committed state
• In the partially committed state, a transaction
executes its final operation, but the data is
still not saved to the database.
• Still, all the changes made by the transaction
are stored in the buffer in main memory, but
they are not updated in the database.
• From partially committed state, a transaction
can go into one of two states, a committed
state or a failed state.
 Failed state
• If any of the checks made by the database
recovery system fails, then the transaction is
said to be in a failed state.
• In the example of total mark calculation, if the
database is not able to fire a query to fetch
the marks, then the transaction will fail to
execute.
 Aborted state
• If any of the checks fail and the transaction has reached a failed
state then the database recovery system will make sure that the
database is in its previous consistent state. If not then it will
abort or roll back the transaction to bring the database into a
consistent state.
• If the transaction fails in the middle of the transaction then
before executing the transaction, all the executed transactions
are rolled back to their consistent state.
• After aborting the transaction, the database recovery module
will select one of the two operations:
– Re-start the transaction
– Kill the transaction
 Committed state
• A transaction is said to be in a committed state
if it executes all its operations successfully.
• In this state, all the effects are now permanently
saved on the database system.
• After a transaction has entered the committed
state, it is not possible to roll back (undo) the
transaction. This is because the system is
updated into a new consistent state and the
changes are made permanent.
 ACID Properties
• A transaction is a very small unit of a program and
it may contain several low-level tasks.
• A transaction in a database system must maintain
the properties commonly known as ACID
properties to ensure accuracy, completeness, and
data integrity.
 Atomicity
• This property states that a transaction must be treated
as an atomic unit, that is, either all of its operations
are executed or none.

• There must be no state in a database where a

transaction is left partially completed.

• States should be defined either before the execution

of the transaction or after the
execution/abortion/failure of the transaction.
Cont…
 Consistency
• The database must remain in a consistent
state after any transaction.
• No transaction should have any adverse effect
on the data residing in the database.

• If the database was in a consistent state

before the execution of a transaction, it must
remain consistent after the execution of the
transaction as well.
Cont…
 Isolation
• In a database system “where more than one
transaction are being executed
simultaneously and in parallel”, the property
of isolation states that all the transactions will
be carried out and executed as if it is the only
transaction in the system.

• No transaction will affect the existence of any

other transaction.
Cont…
 Durability
• The database should be durable enough to hold all its
latest updates even if the system fails or restarts.

• If a transaction updates a chunk of data in a database

and commits, then the database will hold the modified
data.

• If a transaction commits but the system fails before the

data could be written on to the disk, then that data will
be updated once the system springs back into action.
 Transaction Control Language (TCL)
• Transaction control statements manage changes
made by DML statements.

• What is a Transaction?
A transaction is a set of SQL statements which Oracle
treats as a Single Unit. i.e. all the statements should
execute successfully or none of the statements
should execute.
• To control transactions Oracle does not
make any DML statements permanent
unless you commit it.

• If you don’t commit the transaction and

the power goes off or the system crashes
then the transaction is rollbacked.
 TCL Statements
• COMMIT: used to permanently save any
transaction into the database.

• ROLLBACK: restores the database to the last

committed state.

• SAVEPOINT: used to temporarily save a

transaction so that you can roll back to that point
whenever required.
 COMMIT
The syntax of COMMIT Statement is

COMMIT ;

Example

>insert into emp (empno, ename, sal) values (101,’Abid’,2300);

>commit;
 ROLLBACK

• To roll back the changes done in a transaction give

a rollback statement.

• Rollback restores the state of the database to the last

commit point.

Example:
delete from emp;
rollback; /* undo the changes */
 SAVEPOINT
Specify a point in a transaction to which later you can roll
back.
Examples:
insert into emp (empno, ename, sal)
values (109,’Sami’,3000);
savepoint a;

insert into dept values (10,’Sales’,’Hyd’);

savepoint b;

insert into salgrade values (‘III’,9000,12000);

 Characterizing Schedules Based
on Recoverability
Introduction
•In the field of database systems, one of the most important
concepts is that of recoverability.
•Recoverability refers to the ability of a system to restore its
state in the event of failure.
•A schedule is a sequence of transactions that are
executed by a system.
•The order in which these transactions are executed can
have a major impact on the recoverability of a system.
 Cont…
A schedule S of n transactions
•T1, T2, … , Tn is an ordering of the operations of the
transactions.

• Operations from different transactions can be

interleaved in schedule S.

•The operations of the transactions are :

1.Read
2.Write
3.Commit or Abort
 Characterizing Schedules Based
on Recoverability Types

Schedules

Irrecoverable Recoverable with Cascadeless

Schedule Cascading Rollback Recoverable Schedule
 Irrecoverable schedule:
• Irrecoverable schedule refers to a situation where a
transaction in a concurrent environment is committed
before a transaction that precedes it in the serial order,
but which the later transaction depends on.
• Drawback:-
– An irrecoverable schedule can lead to data
inconsistencies and violates the ACID properties of a
transaction.
– To avoid this, DBMS uses concurrency control
techniques such as locking and timestamps to ensure that
transactions are executed in a serializable manner.
– If a schedule is found to be irrecoverable, the only solution
is to abort one or more of the transactions involved and
start over with a new schedule.
• Irrecoverable schedule: The schedule will be
irrecoverable if Tj reads the updated value of
Ti and Tj committed before Ti commit.
Irrecoverable schedule:
•The above table 1 shows a schedule which has
two transactions. T1 reads and writes the value
of A and that value is read and written by T2. T2
commits but later on, T1 fails. Due to the failure,
we have to rollback T1. T2 should also be
rollback because it reads the value written by
T1, but T2 can't be rollback because it already
committed. So this type of schedule is known as
irrecoverable schedule.
Recoverable with cascading rollback :
• Cascading rollback refers to a process where a transaction is rolled
back, and all dependent transactions are also rolled back in a
cascading manner. This ensures that the database remains
consistent and that all changes made by the transactions are undone
in a coordinated manner.
• if a transaction fails or encounters an error, it should be possible to
undo the changes made by the transaction so that the database
remains consistent.
• To ensure recoverability with cascading rollback, the DBMS must
maintain a log of all transactions and their effects on the database.
This log is used to undo the changes made by a transaction in case
of a failure or error.
 Recoverable with cascading rollback: The schedule will be recoverable with
cascading rollback if Tj reads the updated value of Ti. Commit of Tj is delayed till
commit of Ti.

The above table 2 shows a schedule with two transactions. Transaction T1 reads
and writes A, and that value is read and written by transaction T2. But later on,
T1 fails. Due to this, we have to rollback T1. T2 should be rollback because T2
has read the value written by T1. As it has not committed before T1 commits so
we can rollback transaction T2 as well. So it is recoverable with cascade rollback.
 Cascade less Recoverable Schedule:
• Cascade less recoverable schedules are a type of transaction
schedule in database management systems (DBMS) that
guarantee both cascade lessness and recoverability.
• A cascade less recoverable schedule ensures both of these
properties by using strict two-phase locking, where locks are
acquired on all data items accessed by a transaction before any
updates are made, and the locks are held until the transaction is
either committed or aborted.
Cascade less recoverable schedule :
The below Table shows a schedule with two transactions. Transaction T1
reads and write A and commits, and that value is read and written by T2. So
this is a cascade less recoverable schedule. But if T1 fails before commit, no
other transaction has read its value, so there is no need to rollback other
transaction. So this is a Cascade less recoverable schedule.

if Tj reads value updated by Ti only after Ti is committed, the schedule will be

cascadeless recoverable.
• The above table 2 shows a schedule with two
transactions. Transaction T1 reads and writes
A, and that value is read and written by
transaction T2. But later on, T1 fails. Due to
this, we have to rollback T1. T2 should be
rollback because T2 has read the value written
by T1. As it has not committed before T1
commits so we can rollback transaction T2 as
well. So it is recoverable with cascade rollback.
 Characterizing Schedules Based
on Serializability
Schedule:
A series of operations from one transaction to
another transaction is known as a schedule.
It is used to preserve the order of the operation in each
of the individual transactions.
1. Serial Schedule
•All the transactions execute serially one after the other.
•When one transaction executes, no other transaction is allowed
to execute.
Advantages:-
1.Serializable schedules are preferred over non-serializable
schedules because they ensure consistency and avoid conflicts in
the database.
For example: Suppose there are two transactions T1 and T2
which have some operations. If it has no interleaving of
operations, then there are the following two possible outcomes:

– Execute all the operations of T1 which were followed by all

the operations of T2.
– Execute all the operations of T2 which were followed by all
the operations of T1.
 In the given (a) figure, Schedule A shows
the serial schedule where T1 is followed by
T2.

In the given (b) figure, Schedule B shows

the serial schedule where T2 is followed by
T1.
2.Non-serial Schedule:-
•In non-serial schedules, multiple transactions
execute concurrently.
•Operations of all/some of the transactions are
inter-leaved or mixed with each other.
•Some non-serial schedules may lead to
inconsistency of the database and may produce
wrong results.
In the given figure (c) and (d), Schedule C
and Schedule D are the non-serial
schedules. It has interleaving of operations.
3. Serializable schedule
•A non-serial schedule of ‘n’ transactions is
equivalent to some serial schedule of ‘n’
transactions, then it is called as a serializable
schedule.
•In other words, the results produced by the
transactions in a serial schedule are equal to the
result produced by the same transactions in
some non-serial schedule, then that non serial
schedule is called as serializability.
•Serializable schedules behave exactly same as
serial schedules.
• Even though, Serial Schedule and Serializable Schedule
produce same result, there are some differences they are
 Characterizing Schedules Based
on Serializability
Serializability:
•Serializability is a property of a transaction schedule that ensures that the
outcome of a schedule is equivalent to the outcome of its transactions
executed serially, without overlapping in time.
•It is a way to check if the execution of two or more transactions maintains the
consistency of the database.
•Serializability guarantees that the execution of multiple transactions in
parallel does not produce any unexpected or incorrect results.

Serializability

Conflict
View Serializability
Serializability
Non-serializable Schedule Types:-
Non-serializable
schedule

Recoverable Non-Recoverable
Schedule Schedule

Recoverable Schedule:-It ensure that if a

transaction fails, the effects of that transaction
can be undone.
Non-Recoverable Schedule:-Non-recoverable
schedules do not provide this guarantee.
• Conflict Serializability:-
– It can be used in the context of concurrency control
in databases.
– Conflict serializability occurs when two or more
transactions in a schedule access the same data item,
and at least one of them is a write operation.
– A schedule is called conflict serializable if it can be
transformed into a serial schedule by swapping non-
conflicting operations
• Goal of Conflict Serializability:-
1.To ensure that concurrent transactions do not
interfere with each other.
2.The consistency of the database is preserved.
• How to Check The Conflict Serializability:-
We can use a precedence graph or a
serialization graph.
• Drawback Of Non-serializable schedules :-
Non-serializable schedules can lead to various
anomalies such as dirty reads,
non-repeatable reads,
and phantom reads.
• Mechanisms to overcome Non-serializable
schedules :-
To ensure the consistency of the database, it is
important to enforce serializability by using
concurrency control mechanisms such as locking,
timestamp ordering, and optimistic
concurrency control.
 Testing for Serializability of a Schedule
• Serialization Graph or precedence graph is used to test the Serializability
of a schedule.
• Assume a schedule S. For S, we construct a graph known as precedence
graph. This graph has a pair G = (V, E), where V consists a set of vertices,
and E consists a set of edges. The set of vertices is used to contain all the
transactions participating in the schedule. The set of edges is used to
contain all edges Ti ->Tj for which one of the three conditions holds:
– Create a node Ti → Tj, if Ti executes write (X) before Tj executes
read (X).
– Create a node Ti → Tj, if Ti executes read (X) before Tj executes
write (X).
– Create a node Ti → Tj, if Ti executes write (X) before Tj executes
write (X).
Testing for Serializability of a Schedule
• If a precedence graph contains a single edge
Ti → Tj, then all the instructions of Ti are executed
before the first instruction of Tj is executed.
• If a precedence graph for schedule S contains
a cycle, then S is non-serializable.
• If the precedence graph has no cycle, then S is
known as serializable.
Example-1
 2

The precedence graph for schedule S1 contains a cycle

that's why Schedule S1 is non-serializable.
Example-2
The precedence graph for schedule S2 contains no
cycle that's why ScheduleS2 is serializable.
 Conflicts serializable schedules
Problem-01: Check whether the given schedule S is conflict serializable or not.
S : R1(A) , R2(A) , R1(B) , R2(B) , R3(B) , W1(A) , W2(B)
Solution:
Given that S : R1(A) , R2(A) , R1(B) , R2(B) , R3(B) , W1(A) , W2(B) . Schedule-1
The schedule for the above operations is
T1 T2 T3
Read(A)
Read(A)
Read(B)
Read(B)
Read(B)
•List all the conflicting operations and
determine the dependency between the transactions Write(A)
•(Thumb rule to find conflict operations: For each Write(X) in Ta, make a pairWrite(B)
with each Read(X) and Write(X)
in Tb.
•The order is important in each pair i.e., for example, Read after Write on X or write after read on X in the
given schedule.)
 R2(A) , W1(A) (T2 → T1)
 R1(B) , W2(B) (T1 → T2)
 R3(B) , W2(B) (T3 → T2)
 Conflicts in schedules
Draw the precedence graph:

There exists a cycle in the above graph. Therefore, the schedule S is not conflict
serializable.
 Check for Serializability

Serializability

Yes
Conflict Serializability? Serializable

No s
Ye

View Serializability? No Non-

Serializable
 Concurrency Control

• In a multiprogramming environment where multiple

transactions can be executed simultaneously, controlling
the concurrency of transactions is highly important.
• We have concurrency control protocols to ensure
concurrent transactions' atomicity, isolation, and
serializability.
• Concurrency control protocols can be broadly divided
into two categories −

– Lock based protocols

– Time stamp-based protocols
 Lock-based Protocols
• In this type of protocol, any transaction cannot read or write data
until it acquires an appropriate lock on it.
• There are two types of locks available Shared S(a) and Exclusive
X(a).
1. Shared lock:
– It is also known as a Read-only lock. In a shared lock, the data item can only
read by the transaction.
– It can be shared between the transactions because when the transaction holds
a lock, then it can't update the data on the data item.
2. Exclusive lock:
– In the exclusive lock, the data item can be both read as well as written by the
transaction.
– This lock is exclusive, and in this lock, multiple transactions do not modify
the same data simultaneously.
 Locking protocols
Two-Phase Locking 2PL:
•A transaction is said to follow the Two-Phase Locking protocol if
locking and unlocking can be done in two phases.
1. Growing Phase: New locks on data items may be acquired but none can
be released.
2. Shrinking Phase: Existing locks may be released but no new locks can
be acquired.
•If lock conversion is allowed, then upgrading of lock( from S(a) to
X(a) ) is allowed in the Growing Phase, and downgrading of lock
(from X(a) to S(a)) must be done in shrinking phase.
Let’s see a transaction implementing 2-PL.

The skeleton transaction shows how unlocking

and locking work with 2-PL.

Transaction T1:

The growing Phase is from steps 1-3.

The shrinking Phase is from steps 5-7.
Lock Point at 3

Transaction T2:

The growing Phase is from steps 2-6.

The shrinking Phase is from steps 8-9.
Lock Point at 6

What is LOCK POINT? The Point at which the

growing phase ends, i.e., when a transaction
takes the final lock it needs to carry on its work.
Advantages:
2-PL ensures serializability.

Disadvantages:
It does not ensure recoverability as it suffers from
Cascading Rollback.
It may suffer from deadlock.
Cascading Rollbacks in 2-PL –

Because of Dirty Read in T2 and T3 in lines 8 and 12 respectively, when T1 failed we

have to roll back others also. Hence, Cascading Rollbacks are possible in 2-PL.
Deadlock in 2-PL –
•In a multi-process system, deadlock is an unwanted situation that
arises in a shared resource environment, where a process indefinitely
waits for a resource that is held by another process.
•Assume a set of transactions {T0, T1, T2, ...,Tn}.
•T0 needs a resource X to complete its task.
• Resource X is held by T1, and T1 is waiting for resource Y, which is
held by T2.
•T2 is waiting for resource Z, which is held by T0. Thus, all the
processes wait for each other to release resources.
•In this situation, none of the processes can finish their task.
•This situation is known as a deadlock.

In case a system is stuck in a deadlock, the transactions involved in

the deadlock are either rolled back or restarted.
Example
Let T1 and T2 are two transactions.

T1=A+B and T2=B+A

Here,

T1: Lock-X(B) : Cannot execute Lock-X(B) since B is locked by T2.

T2: Lock-X(A) : Cannot execute Lock-X(A) since A is locked by T1.

In the above situation T1 waits for B and T2 waits for A. The waiting time never
ends. Both the transaction cannot proceed further at least any one releases the lock
voluntarily. This situation is called deadlock.

The wait for graph is as follows −

Wait for graph: It is used in the deadlock detection
method, creating a node for each transaction, creating an
edge Ti to Tj, if Ti is waiting to lock an item locked by Tj. A
cycle in WFG indicates a deadlock has occurred. WFG is
created at regular intervals.

Schedule: Lock-X1(A) Lock-X2(B) Lock-X1(B) Lock-X2(A)

 Data Backup

Loss of Volatile Storage:

Volatile storage like RAM stores all the active logs, disk buffers,
and related data.

In addition, it stores all the transactions that are being currently

executed.

What happens if such a volatile storage crashes

Following techniques may be adopted in case of loss of
volatile storage −


We can have checkpoints at multiple stages so as to save
the contents of the database periodically.

A state of active database in the volatile memory can be



periodically dumped onto a stable storage, which may also

contain logs and active transactions and buffer blocks.


<dump> can be marked on a log file, whenever the
database contents are dumped from a non-volatile memory
to a stable one.
Recovery
When the system recovers from a failure, it
•

can restore the latest dump.

It can maintain a redo-list and an undo-list

•

as checkpoints.

It can recover the system by consulting undo-

•

redo lists to restore the state of all

transactions up to the last checkpoint.
 Database Backup & Recovery from Catastrophic
Failure

A catastrophic failure is one where a stable,

secondary storage device gets corrupt.

With the storage device, all the valuable data

that is stored inside is lost.
We have two different strategies to recover data
from such a catastrophic failure −


Remote backup: Here a backup copy of the database is
stored at a remote location from where it can be restored
in case of a catastrophe.


Alternatively, database backups can be taken on
magnetic tapes and stored at a safer place. This backup
can later be transferred onto a freshly installed database
to bring it to the point of backup.
 Remote Backup
Remote backup provides a sense of security in case the
primary location where the database is located gets
destroyed.
Remote backup can be offline or real-time or online. In case
it is offline, it is maintained manually.
• Online backup systems are more real-time and lifesavers
for database administrators and investors.

• An online backup system is a mechanism where every bit

of the real-time data is backed up simultaneously at two
distant places.

• One of them is directly connected to the system and the

other one is kept at a remote place as backup.

• As soon as the primary database storage fails, the backup

system senses the failure and switches the user system to
the remote storage.
• Sometimes this is so instant that the users can’t even
realize a failure.
 Data Recovery
1. Crash Recovery:
DBMS is a highly complex system with hundreds of
transactions being executed every second.

The durability and robustness of a DBMS depends on

its complex architecture and its underlying hardware
and system software.

If it fails or crashes amid transactions, it is expected

that the system would follow some sort of algorithm or
techniques to recover lost data.
Failure Classification:
1. Transaction failure
2. System Crash
3. Disk Failure
 Transaction failure

A transaction has to abort when it fails to execute or when it

reaches a point from where it can’t go any further. This is
called transaction failure where only a few transactions or
processes are hurt.
Reasons for a transaction failure could be −

Logical errors − Where a transaction cannot complete
because it has some code error or any internal error
condition.

System errors − Where the database system itself
terminates an active transaction because the DBMS is not
able to execute it, or it has to stop because of some system
condition. For example, in case of deadlock or resource
unavailability, the system aborts an active transaction.
 System Crash

There are problems − external to the system − that

may cause the system to stop abruptly and cause the
system to crash.

For example, interruptions in power supply may

cause the failure of underlying hardware or
software failure.

Examples may include operating system errors.

 Disk Failure

In early days of technology evolution, it was a common

problem where hard-disk drives or storage drives used
to fail frequently.

Disk failures include formation of bad sectors,

unreachability to the disk, disk head crash or any other
failure, which destroys all or a part of disk storage.
 Recovery and Atomicity
When a system crashes, it may have several transactions
being executed and various files opened for them to modify
the data items.

Transactions are made of various operations, which are

atomic in nature.

But according to ACID properties of DBMS, atomicity of

transactions as a whole must be maintained, that is, either
all the operations are executed or none.
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.
<Tn, Start>

When the transaction modifies an item X, it write logs as follows −

<Tn, X, V1, V2>

It reads Tn has changed the value of X, from V1 to V2.

When the transaction finishes, it logs −

<Tn, commit>
 Recovery with Concurrent Transactions

When more than one transaction are being executed in

parallel, the logs are interleaved.

At the time of recovery, it would become hard for the

recovery system to backtrack all logs, and then start
recovering.

To ease this situation, most modern DBMS use the

concept of 'checkpoints'
 Checkpoint
Keeping and maintaining logs in real time and in real
environment may fill out all the memory space available in
the system.

As time passes, the log file may grow too big to be handled
at all.

Checkpoint is a mechanism where all the previous logs are

removed from the system and stored permanently in a
storage disk.

Checkpoint declares a point before which the DBMS was

in consistent state, and all the transactions were committed.
 Recovery
When a system with concurrent transactions crashes and recovers, it
behaves in the following manner −

The recovery system reads the logs backwards
from the end to the last checkpoint.

It maintains two lists, an undo-list and a redo-list.

If the recovery system sees a log with
<Tn, Start> and <Tn, Commit> or just
<Tn, Commit>,
it puts the transaction in the redo-list.

If the recovery system sees a log with
<Tn, Start> but no commit or abort log
found, it puts the transaction in undo-list.
 All the transactions in the undo-list are then undone and
their logs are removed.
All the transactions in the redo-list and their previous
logs are removed and then redone before saving their
logs.
Consider the following log sequence of two If the database crashes at point 7,
transactions on a bank account: With an initial everything until point 4 (including) is
balance of 12000, transfer 2000 to a mortgage already on disk. That is the guarantee that
payment and then apply a 5% interest. commit gives.

1.T1 start During recovery basically the state after

2.T1 B old=12000 new=10000 point 4 is restored.
3.T1 M old=0 new=2000
4.T1 commit
5.T2 start
6.T2 B old=10000 new=10500
7.T2 commit
Immediate Update:
Deferred Update
• It is a technique for the maintenance of the transaction log
files of the DBMS. It is also called NO-UNDO/REDO technique.
• It is used for the recovery of transaction failures that occur
due to power, memory, or OS failures.
• Whenever any transaction is executed, the updates are not
made immediately to the database.
• They are first recorded on the log file and then those changes
are applied once the commit is done. This is called the “Re-
doing” process.
• Once the rollback is done none of the changes are applied to
the database and the changes in the log file are also
discarded.
• If the commit is done before crashing the system, then after
restarting the system the changes that have been recorded in
the log file are thus applied to the database.
• Deferred Database Modification(Log-based recovery):
A=100 200
B=200 400 (after commit the new values will get replaced in DB)
DB
T1 <T1,start> <T1,start>
R(A) 100 <T1,A,200> <T1,A,200>
A=A+100 <T1,B,400> <T1,B,400>
W(A) 200 <T1,commit> <T1,commit>
R(B) 200 Redo <T2,start>
B=B+200 A=200 <T2,C,500>
W(B) 400 B=400

Commit if not committed performs rollback operations and values become

A=100, B=200
Shadow Paging:

Shadow paging is one of the techniques that is used to recover from failure. We all know that
recovery means getting back the information, which is lost. It helps to maintain database
consistency in case of failure.

Concept of shadow paging:

Step 1 − Page is a segment of memory. Page table is an index of pages. Each table entry
points to a page on the disk.

Step 2 − Two page tables are used during the life of a transaction: the current page table and
the shadow page table. Shadow page table is a copy of the current page table.

Step 3 − When a transaction starts, both the tables look identical, the current table is updated
for each write operation.

Step 4 − The shadow page is never changed during the life of the transaction.

Step 5 − When the current transaction is committed, the shadow page entry becomes a copy of
the current page table entry and the disk block with the old data is released.

Step 6 − The shadow page table is stored in non-volatile memory. If the system crash occurs,
then the shadow page table is copied to the current page table.
To understand concept, consider above figure. In this 2 write operations are
performed on page 3 and 5. Before start of write operation on page 3, current page
table points to old page 3. When write operation starts following steps are
performed :

Firstly, search start for available free block in disk blocks.

After finding free block, it copies page 3 to free block which is represented by Page
3 (New).
Now current page table points to Page 3 (New) on disk but shadow page table
points to old page 3 because it is not modified.
The changes are now propagated to Page 3 (New) which is pointed by current
page table.
Advantages

The advantages of shadow paging are as follows −

•No need for log records.

•No undo/ Redo algorithm.
•Recovery is faster.

Disadvantages

The disadvantages of shadow paging are as follows −

•Data is fragmented or scattered.

•Garbage collection problem. Database pages containing old versions of modified data
need to be garbage collected after every transaction.
•Concurrent transactions are difficult to execute.