Unit-7

Transaction
Processing
What is transaction?
 A transaction is a sequence of operations performed as a single
logical unit of work.
 A transaction is a logical unit of work that contains one or more
SQL statements.
Work as a single
 Example of transaction logical unit
read (A)
A = A – 50
Transaction write (A)
Operations
read (B)
B = B + 50
write (B)
Property of
transaction
ACID property of transaction
 ACID property
• Atomicity
• Consistency
• Isolation
• Durability
ACID property of transaction
• Atomicity 0%
– This property states that a transaction read (A)
must be treated as an atomic unit, that
is, either all of its operations are
A = A – 50
executed or none. write (A)
FAIL
– Either transaction execute 0% or read (B)
100%.
B = B + 50
– For example consider a transaction to
transfer Rs. 50 from account A to write (B)
account B. 100%

– In this transaction if Rs. 50 is deducted

from account A then it must be added
to account B.
ACID property of transaction
• Consistency A=500, B=500
– The database must remain in a A+B=1000
consistent state after any transaction.
read (A)
– If the database was in a consistent
state before the execution of a A = A – 50
transaction, it must remain consistent write (A)
after the execution of the transaction
as well.
read (B)
– In our example total of A and B must B = B + 50
remain same before and after the write (B)
execution of transaction.
A=450, B=550
A+B=1000
ACID property of transaction
• Isolation read (A)
– A transaction in process and not yet A = A – 50
committed must remain isolated from
any other transaction.
write (A)
– Intermediate transaction results must read (B)
be hidden from other concurrently B = B + 50
executed transactions.
write (B)
– In our example once your transaction
start from step one its result should
not be access by any other transaction
until last step (step 6) is completed.
ACID property of transaction
• Durability A=500, B=500
– After a transaction completes read (A)
successfully, the changes it has made
to the database persist, even if
A = A – 50
there are system failures. write (A)
– Once your transaction completed up to read (B)
step 6 its result must be stored
permanently. It should not be removed
B = B + 50
if system fails. write (B)
A=450, B=550
 Transaction
State Diagram
Transaction State Diagram \ State Transition Diagram

read (A)
Partial
Committed Committed A = A – 50
write (A)
Active End read (B)
B = B + 50
Failed Aborted
write (B)
Commit
Transaction State Diagram \ State Transition Diagram

1.Active:

 It is the initial state if a transaction.

 Execution of transaction starts in an active state.

 Transaction remains in an active state till its execution is in process.

2. Partially Committed:

 When the last operation of a transaction is executed it goes to a

partially committed state.

 Here there is a possibility that the transaction may be aborted or else

it goes to committed state.
Transaction State Diagram \ State Transition Diagram
3.Failed:
 A transaction goes to a Failed state if it is determined that it can no
longer proceed with its normal execution.
4.Aborted:
 Failed transaction when rolled back is in an aborted state.
 In this stage system has two options:
1. Restart the transaction: A restarted transaction is considered to
be new transaction which may recover from possible failure.
2. Kill the transaction: A transaction can be killed to recover from
failure.
5.Committed:
 The transaction when successfully completed comes to this state.
 Transaction is said to be terminated if its neither committed nor
aborted.
Transaction
Schedule
What is schedule?
 A schedule is a process of grouping the transactions into one
and executing them in a predefined order.
 A schedule is the sequential order in which instructions are
executed in a system.
 A schedule is required in a database because when some
transactions execute in parallel, they may affect the result of
the transaction.
 Means if one transaction is updating the values which the other
transaction is accessing, then the order of these two
transactions will change the result of second transaction.
 Hence a schedule is created to execute the transactions.
 There are 2 types of schedule:
1. Serial schedule
2. Concurrent Transactions/ Interleaved schedule
Serial schedule/Transactions/Execution
 A serial schedule is one in which no transaction starts until a
running transaction has ended.
 Transactions are ordered one after the other.
 This type of schedule is called a serial schedule, as transactions
are executed in a serial manner.
Example of serial schedule
T1 T2
Read (A)
A = A -100
Write (A)
Read (B)
B = B + 100
Write (B)
Commit
Read (A)
A = A - 50
Write (A)
Read (B)
B = B + 50
Write (B)
Commit
Example of serial schedule
T1 T2
Read (A)
A = A - 50
Write (A)
Read (B)
B = B + 50
Write (B)
Commit
Read (A)
A = A -100
Write (A)
Read (B)
B = B + 100
Write (B)
Commit
Concurrent Transactions/ Interleaved schedule
 Schedule that interleave the actions of different transactions.
 Means second transaction is started before the first one could
end.
 And execution can switch between the transactions back and
so on.
 Transaction processing allows multiple transactions to be
executed simultaneously on database server.
 Allowing multiple transactions to change data in database
concurrently causes several complications with consistency of
the data in database.
 It was very simple to main consistency in case of serial
execution as compare to concurrent execution of transactions.
Concurrent Transactions/ Interleaved schedule
Advantages:
Improved Throughput:
 It defines as the number of transactions executed in a given amount
of time.
 If we are executing multiple transactions simultaneously that may
increase throughput considerably.
Resource Utilization:
 It is defined as the processor and disk performing useful work or
not(in idle state)
 The processor and disk utilization increase as number of concurrent
transactions increases.
Reduced waiting time:
 There may be some small transaction and some long transactions
may be executing on a system.
 If transactions are running serially, a short transaction may have to
wait for a earlier long transaction to complete, which can lead to
random delays in running a transaction.
Example of interleaved schedule
T1 T2
Read (A)
A = A - 100
Write (A)

Read (A)
A = A - 50
Write (A)

Read (B)
B = B + 100
Write (B)
Commit
Read (B)
B = B + 50
Write (B)
Commit
Example of interleaved schedule
T1 T2
Read (A)
A = A - 50
Write (A)
Read (A)
A = A - 100
Write (A)

Read (B)
B = B + 50
Write (B)
Commit
Read (B)
B = B + 100
Write (B)
Commit
Equivalent schedule
T1 T2 T1 T2
Read (A) Read (A)

Both schedule are equivalent

A = A - 50 A = A - 50
Write (A) Write (A)
Read (A) Read (B)
A = A - 100 B = B + 50
Write (A) Write (B)
Commit
Read (A)
Read (B) A = A - 100
B = B + 50 Write (A)
Write (B) Read (B)
Commit Read (B) B = B + 100
B = B + 100 Write (B)
Write (B) Commit
Commit
.
Serializability
Serializability/Serializable Schedule
 The database system must control concurrent execution of
transactions Serializability will ensure that the database state
remains in consistent state.
 We first need to understand which schedules will ensure
consistency, and which schedules will not.
 A schedule is the actual execution sequence of concurrent
transactions.
 A schedule of two transactions T1 and T2 is ‘serializable’ if and
only if executing this schedule has the same effect as any serial
schedule (either T1:T2 or T2:T1).
 We consider only two operations: Read and Write for purpose
of computational simplicity.
Serializability
 A schedule is serializable if it is equivalent to a serial schedule.
 Types (forms) of serializability
1. Conflict serializability
2. View serializability
 Conflict
Serializability
Conflicting instructions
 Let li and lj be two instructions of transactions Ti and Tj
respectively.
1. li = read(Q), lj = read(Q) li and lj don’t conflict.
2. li = read(Q), lj = write(Q) They conflict.
3. li = write(Q), lj = read(Q) They conflict
4. li = write(Q), lj = write(Q) They conflict

 Instructions li and lj conflict if and only if there exists some item

Q accessed by both li and lj, and at least one of these
instructions wrote Q.
 If both the transactions access different data item then they are
not conflict and can be swapped, without any problem.
Conflict Serializability
 If a schedule S can be transformed into a schedule S1 by a
series of swaps of non-conflicting instructions, we say that S
and S1 are conflict equivalent.
 We say that a schedule S is conflict serializable if it is conflict
equivalent to a serial schedule
Conflict operations
 Operations are said to be conflicting if,
1. Belongs to different transactions.
2.Access to same database item.
3.Atleast one of them is write operation.
Conflict equivalence
 Two schedules are conflict equivalence if they can be turned
into one another by a sequence of non conflicting swaps of
adjacent actions.

0R
 Two schedules are said to be conflict equivalence if all
conflicting operations in both the schedule must be executed in
the same order.
Conflict Serializability (example)
T1 T2 T1 T2
Read (A) Read (A)
A = A - 50 A = A - 50
Write (A) Write (A)
Read (B) Read (A)
B = B + 50 Temp = A * 0.1
Write (B) A = A - temp
Commit Write (A)
Read (A)
Temp = A * 0.1 Read (B)
A = A - temp B = B + 50
Write (A) Write (B)
Read (B) Commit Read (B)
B = B + temp B = B + temp
Write (B) Write (B)
Commit Commit
Conflict Serializability (example)
Conflict serializability (example)
Conflict Serializability (example)
Conflict Serializability (example)
Conflict Serializability (example)
Conflict Serializability
 Example of a schedule that is not conflict serializable:
T1 T2
Read (A)
Write (A)
Read (A)

 We are unable to swap instructions in the above schedule to

obtain either the serial schedule < T1, T2 >, or the serial
schedule < T2, T1 >.
 View
Serializability
View Serializability
 Let S and S1 be two schedules with the same set of
transactions. S and S1 are view equivalent if the following
three conditions are met, for each data item Q
1. If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S1 also transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that value was
produced by transaction Tj (if any), then in schedule S1 also
transaction Ti must read the value of Q that was produced by the same
write(Q) operation of transaction Tj.
3. If Ti performs the final write on the data value in S, then it also
performs the final write on the data value in S2.
• First 2 conditions ensure that transaction reads same value in both
schedule.
• Condition 3 ensure the final consistent state.
• If a concurrent schedule is view equivalence to a serial schedule to a
serial schedule of same transaction then it is view serializable.
View Serializable schedules
T1 T2 T3 T2 T3 T1
Read (A) Read (A)
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (A)
Write (A) Write (A)

 Initial read √
 Write-read conflict √
 Final write √

View
Serializable Conflict
Serializable
Concurrency
Control
What is concurrency?
 Concurrency is the ability of a database to allow
multiple (more than one) users to access data at the
same time.
 Three problems due to concurrency
1. The lost update problem
2. The dirty read problem
3. Unrepeatable Read Problem
4. Incorrect Summary Problem
The lost update problem
The dirty read problem
Unrepeatable Read Problem
Incorrect Summary Problem
 Concurrency
Control Schemes
What is lock?
 A lock is a variable associated with data item to control
concurrent access to that data item.

Lock variable
0

Database
What is lock?
 A lock is a variable associated with data item to control
concurrent access to that data item.
Locking is a strategy that is used
to prevent such concurrent
updates to data.

Lock variable
1

Database
What is lock?
 A lock is a variable associated with data item to control
concurrent access to that data item.

Lock variable
0

Database
Lock Based
Protocol
Lock based protocol
Lock based protocol
 Data items can be locked in two modes :
1. Shared (S) mode: When we take this lock we can just read the item
but cannot write.
2. Exclusive (X) mode: When we take this lock we can read as well as
write the item.
Lock based protocol
 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqq
Lock based protocol
Lock based protocol
Lock based protocol
Lock based protocol
Lock based protocol
Lock based protocol
 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.
 If a lock cannot be granted, the requesting transaction is made
to wait till all incompatible locks held by other transactions
have been released. The lock is then granted.
 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.
Lock based protocol
 This locking protocol divides transaction execution phase into
three parts:
1. When transaction starts executing, transaction seeks grant for locks it
needs as it executes.
2. Where the transaction acquires all locks and no other lock is required.
Transaction keeps executing its operation.
3. As soon as the transaction releases its first lock, the third phase starts.
In this phase a transaction cannot demand for any lock but only
releases the acquired locks.
Transaction
Lock acquisition execution Lock releasing
phase phase

Transaction

T begin T end Time

 2PL
(Two phase
locking
protocol)
2PL (Two phase locking protocol)
 This protocol can be divided into two phases,
1. Growing Phase
• In this phase a transaction obtains locks, but may not release any lock.
• When a transaction takes the final lock is called lock point.
2. Shrinking Phase
• In this phase a transaction may release locks, but may not obtain any
lock.
• The transaction enters the shrinking phase as soon as it releases the
first lock after crossing the Lock Point.
Growing phase Shrinking phase

Transaction
T begin T end Time
2PL (Two phase locking protocol)
qqqqqq
 Modified
version of
Two phase
locking protocol
Strict two phase locking protocol
 In this protocol, a transaction may release all the shared locks
after the Lock Point has been reached, but it cannot release any
of the exclusive locks until the transaction commits or aborts.
 It ensures that if data is being modified by one transaction,
then other transaction cannot read it until first transaction
commits.
 This protocol solves dirty read problem.
Rigorous two phase locking protocol
 In this protocol, a transaction is not allowed to release any lock
(either shared or exclusive) until it commits.
 This means that until the transaction commits, other
transaction might acquire a shared lock on a data item on
which the uncommitted transaction has a shared lock; but
cannot acquire any lock on a data item on which the
uncommitted transaction has an shared lock.
Lock Conversion : Upgrading and Downgrading
Conversion between the locks is possible by the two methods
listed below:
Upgrading: conversion from a read lock to write lock
Downgrading: conversion from a write lock to read lock

 Problems associated with Simple locking:

1. Data inconsistency between multiple transactions
2. Deadlock, a situation where the transactions try to access lock
on already locked data items
3. No guarantee of Serializability (i.e. execution of a concurrent
transaction equivalent to that of a transaction executed
serially)
Deadlock
What is deadlock?
 A deadlock is a condition wherein two or more tasks are
waiting for each other in order to be finished but none of the
task is willing to give up the resources that other task needs. In
this situation no task ever gets finished and is In waiting state
forever.
 Deadlock is an unwanted condition where two or more
processes waits indefinitely for the other process to free up
their resources so that they can complete their work.
What is deadlock?
 Consider the following two transactions:
T1 T2
Granted for (A) Lock-X (A)
Write (A)
Lock-X (B) Granted for (B)
Write (B)
Lock-X (A) Waiting for (A)
Write (A)
Waiting for (B) Lock-X (B)
Write (B)

 System is deadlocked if there is a set of transactions such that

every transaction in the set is waiting for another transaction
in the set.
What is deadlock?

Transaction Transaction
Hold T1 Request

Request Hold
Table1 DEADLOCK Table2

T2 Hold
Request
Table Table
Deadlock
There are two Principle method to handle deadlock in system.

1.Deadlock Prevention:

We can use deadlock prevention techniques to ensure that the

system will never enter in deadlock state.

2. Deadlock Detection and Recovery:

We can allow the system to enter a deadlock state and then we

can detect such state by deadlock detection techniques and try to
recover from deadlock state by using deadlock recovery scheme.
Deadlock Prevention
Four conditions for a deadlock occurrence. A deadlock may occur if all
the following conditions holds true. (Coffman conditions)
Mutual exclusion condition:
 There must be at least one resource that cannot be used by more
than one process at a time.
Hold and wait condition:
 A process that is holding a resource can request for additional
resources that are Hold and wait condition: being held by other
processes in the system.
No preemption condition:
 A resource cannot be forcibly taken from a process. Only the process
can release a resource that is being held by it.
Circular wait condition:
 A condition where one process is waiting for a resource that is being
held by second process and second process is waiting for third
process, So on and the last process is waiting for the first process.
Thus making a circular chain of waiting.
Deadlock Prevention (Conti..)
 There are deadlock prevention schemes that use timestamp
ordering mechanism of transactions in order to predetermine a
deadlock situation.
1. Wait-Die Scheme
 This is non pre-emptive techniques of deadlock prevention.
 When transaction Ti wants to hold data item, currently hold by
Tj, then Ti is allowed to wait if and only if it is older than Tj
otherwise Ti is rolled back.
 If T1 request for data item hold by T2 then as TS(T1) < TS(T2)
so T1 should wait.
Deadlock Prevention (Conti..)
2.Wound-Wait Scheme
 This is preemptive techniques of deadlock prevention.
 When transaction Ti wants to hold data item, currently hold by
Tj, then Ti is allowed to wait if and only if it is younger to Tj
otherwise Tj is rolled back.(wounded)
 Consider T1,T2,T3 transaction.
 If T1 request for data item hold by T2 then data item is pre-
emted from T2 and given to T1 and T2 is rollback.
 If T3 requests for data item hold by T2 then T3 need to
rollback.
3.Timeout-Based Schemes :
 A transaction waits for a lock only for a specified amount of
time. After that, the wait times out and the transaction is rolled
back. So deadlocks never occur.
 simple to implement; but difficult to determine good value of
the timeout interval.
Deadlock Detection
 The resource scheduler can detect a deadlock as it keeps track
of all the resources that are allocated to different processes.
After a deadlock is detected, it can be resolved using the
following methods:
1. All the processes involved in the deadlock are terminated. This
is not a good approach as all the progress made by the
processes is destroyed.
2. Resources can be preempted from some processes and given
to others till the deadlock is resolved.
Deadlock Detection (Conti..)
Wait for Graph:
 This is the suitable method for deadlock detection. In this method, a
graph is created based on the transaction and their lock. If the
created graph has a cycle or closed loop, then there is a deadlock.
 The wait for the graph is maintained by the system for every
transaction which is waiting for some data held by the others. The
system keeps checking the graph if there is any cycle in the graph.
 The wait for a graph for the above scenario is shown below:
Deadlock Recovery
 When deadlock is detected in the system, then system should
be recovered from deadlock using deadlock recovery schemes.
 A most common solution is rollback one or more transaction to
break the deadlock.
 Method for recover from deadlock are.
Selection of Victims:
 If deadlock is detected, then a transaction one or more victims
to be selected to break the deadlock.
 Transaction with minimum cost should be selected for
rollbacks.
 Cost can be detected by following factors.
1. Which transaction is younger.
2. How many data items it has locked?
3. How many data items it may need ahead?
4. Number of transaction to be rollback.
Deadlock Recovery
Rollback:
1. Total Rollback: The transaction is aborted and restart.
2. Partial Rollback: Rollback the only transaction which is needed
to break the deadlock.
Starvation:
 It may happen every time same transaction is selected as victim
and this may lead to starvation of that transaction.
 System should take care that every time same transaction
should not be selected as victim.so it will not be starved.
 Time stamp
based protocol
Time stamp based protocol
 This protocol uses either system time or logical counter to be
used as a time-stamp.
 Every transaction has a time-stamp associated with it and the
ordering is determined by the age of the transaction.
 A transaction created at 0002 clock time would be older than
all other transaction, which come after it.
 For example, any transaction 'y' entering the system at 0004 is
two seconds younger and priority may be given to the older
one.
 In addition, every data item is given the latest read and write
time-stamp. This lets the system know, when last read was and
write operation made on the data item.
Time stamp ordering protocol
 The timestamp-ordering protocol ensures serializability among
transaction in their conflicting read and writes operations.
 This is the responsibility of the protocol system that the
conflicting pair of tasks should be executed according to the
timestamp values of the transactions.
• Time-stamp of Transaction Ti is denoted as TS(Ti).
• Read time-stamp of data-item X is denoted by R-timestamp(X).
• Write time-stamp of data-item X is denoted by W-timestamp(X).
Time stamp ordering protocol
 Timestamp ordering protocol works as follows:
• If a transaction Ti issues read(X) operation:
• If TS(Ti) < W-timestamp(X)
– Operation rejected.
• If TS(Ti) >= W-timestamp(X)
– Operation executed.

• If a transaction Ti issues write(X) operation:

• If TS(Ti) < R-timestamp(X)
– Operation rejected.
• If TS(Ti) < W-timestamp(X)
– Operation rejected and Ti rolled back.
• Otherwise, operation executed.
Database
Recovery
Database recovery
 Database recovery is the process of restoring the database and
the data to a consistent state.
 This may include restoring lost data up to the point of the event
(e.g. system crash).
 There are many situations in which a transaction may not
reach a commit or abort point.
• An operating system crash can terminate the DBMS processes
• The DBMS can crash
• The system might lose power
• A disk may fail or other hardware may fail.
• Human error can result in deletion of critical data.
 In any of these situations, data in the database may become
inconsistent or lost.
Database recovery
 For example, if a transaction has completed 30 out of 40
scheduled writes to the database when the DBMS crashes, then
the database may be in an inconsistent state as only part of the
transaction’s work was completed.
Log Based
Recovery
Method
Log based recovery method
 A log is kept on stable storage (i.e HDD).
• The log is a sequence of records, which maintains information about
update activities on the database.
 Log contains
1. Start of transaction
2. Transaction-id
3. Record-id
4. Type of operation (insert, update, delete)
5. Old value, new value
6. End of transaction that is committed or aborted.
Log based recovery method
Log based recovery method
 When transaction Ti starts, it registers itself by writing a record
<Ti start> to the log
 Before Ti executes write(X), a log record <Ti, X, V1, V2> is
written, where V1 is the value of X before the write (the old
value), and V2 is the value to be written to X (the new value).
 When Ti finishes it last statement, the log record <Ti commit>
is written.
 Types of log based recovery method
1. Immediate database modification
2. Deferred database modification
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are Updates (changes) to the database are
applied immediately as they occur without deferred (postponed) until the transaction
waiting to reach to the commit point. commits.

A=500, B=600, C=700 T1 T2 A=500, B=600, C=700

Read (A)
A = A - 100
Write (A)
Read (B)
<T1 start> <T1 start>
B = B + 100
< T1, A, 500, 400> < T1, A, 400>
Write (B)
< T1, B, 600, 700> Time A < T1, B, 700>
Commit
Read (C)
C = C - 200
Time B Write (C)
Commit
Time C
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are Updates (changes) to the database are
applied immediately as they occur without deferred (postponed) until the transaction
waiting to reach to the commit point. commits.

A=500, B=600, C=700 T1 T2 A=500, B=600, C=700

Read (A)
A = A - 100
Write (A)
Read (B)
B = B + 100
<T1 start> Write (B) <T1 start>
Time A
< T1, A, 500, 400> Commit < T1, A, 400>
< T1, B, 600, 700> Read (C) < T1, B, 700>
Commit C = C - 200 Commit
<T2 start> Time B Write (C) <T2 start>
< T2, C, 700, 500> Commit < T2, C, 500>
Time C
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are Updates (changes) to the database are
applied immediately as they occur without deferred (postponed) until the transaction
waiting to reach to the commit point. commits.

A=500, B=600, C=700 T1 T2 A=500, B=600, C=700

Read (A)
A = A - 100
Write (A)
Read (B)
<T1 start> B = B + 100 <T1 start>
< T1, A, 500, 400> Write (B) < T1, A, 400>
< T1, B, 600, 700> Time A
Commit < T1, B, 700>
Commit Read (C) Commit
<T2 start> C = C - 200 <T2 start>
< T2, C, 700, 500> Time B Write (C) < T2, C, 500>
Commit Commit Commit
Time C
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are Updates (changes) to the database are
applied immediately as they occur without deferred (postponed) until the transaction
waiting to reach to the commit point. commits.
These updates are also recorded in the During the execution of transaction,
transaction log. It is possible that other updates are recorded only in the
transactions can access these updated transaction log and in buffers. After the
values which is written on database. transaction commits, these updates are
recorded in the database.
If transaction has not committed, then it If transaction has not committed, then it
may have modified the database. So, undo has not affected the database. So, no need
the updates of the transaction and restart to do any undoing operations. Just restart
the transaction again. the transaction.
If transaction has committed, then it is If transaction has committed, then, it is not
updated in the database. So, no need to updated in the database. So, redo the
redo the updates of the transaction. updates of the transaction.
Undo and Redo both operations can be Only Redo operation is performed.
performed.
Problems with Deferred & Immediate Updates
 Searching the entire log is time consuming.
1. Immediate database modification
• When transaction fail log file is used to undo the updates of transaction.
2. Deferred database modification
• When transaction commits log file is used to redo the updates of
transaction.

 To reduce the searching time of entire log we can use check

point.
Checkpoint
Checkpoint
 It is a point which specifies that any operations executed before
it are done correctly and stored safely (updated safely in
database).
 At this point, all the buffers are force-fully written to the
secondary storage (database).
 Checkpoints are scheduled at predetermined time intervals.
 It is used to limit:
• The size of transaction log file
• Amount of searching
Checkpoint works when failure occurs
Time TC Tf

T1
T2
T3

T4

Checkpoint time Failure

 At failure time:
• Ignore the transaction T1 as it has already been committed before
checkpoint.
• Redo transaction T2 and T3 as they are active at/after checkpoint, but have
committed before failure.
• Undo transaction T4 as it is active after checkpoint and has not committed.
Shadow Paging
Technique
Shadow paging technique
 Shadow paging is an alternative to log-based recovery
 This scheme is useful if transactions execute serially.
 It maintain two page tables during the lifetime of a transaction
• current page table
• shadow page table
 Shadow page table is stored on non-volatile storage.
 Shadow page table is never modified during execution of
transaction.
Shadow paging technique
Page 1 Page 1 Page 1
Page 2 Page 2 Page 2
Page 3 Page 3 Page 3
Page 4 Page 4 Page 4
Page 5 Page 5 Page 5

Current page table Pages Shadow page table

 Two pages - page 2 & 5 - are affected by a transaction and

copied to new physical pages. The current page table points to
these pages.
Shadow paging technique
Page 1 Page 1 Page 1
Page 2 Page 2 (old) Page 2
Page 3 Page 3 Page 3
Page 4 Page 4 Page 4
Page 5 Page 5 (old) Page 5
Page 2 (new)
Page 5 (new)
Current page table Pages Shadow page table

 Two pages - page 2 & 5 - are affected by a transaction and

copied to new physical pages. The current page table points to
these pages.
Shadow paging technique
Page 1 Page 1 Page 1
Page 2 Page 2 (old) Page 2
Page 3 Page 3 Page 3
Page 4 Page 4 Page 4
Page 5 Page 5 (old) Page 5
Page 2 (new)
Page 5 (new)
Current page table Pages Shadow page table

 Two pages - page 2 & 5 - are affected by a transaction and

copied to new physical pages. The current page table points to
these pages.
 The shadow page table continues to point to old pages which
are not changed by the transaction. So, this table and pages are
used for undoing the transaction.
Shadow paging technique
 When transaction start, both the page tables are identical.
 The shadow page table is never changed over the duration of
the transaction.
 The current page table may be changed when a transaction
performs a write operation.
 All input and output operations use the current page table.
 Whenever any page is about to be written for the first time
• A copy of this page is made onto an unused page.
• The current page table is then made to point to the copy
• The update is performed on the copy
 When the transaction completes, the current page table
becomes shadow page table. At this time, it is considered that
the transaction has committed.
Shadow paging technique
Page 1 Page 1 Page 1
Page 2 Page 2 (old) Page 2
Page 3 Page 3 Page 3
Page 4 Page 4 Page 4
Page 5 Page 5 (old) Page 5
Page 2 (new)
Page 5 (new)
Current page table Pages Shadow page table
Shadow paging technique
Advantages:
1. Log record overhead is removed.
2. Faster recovery (Not require any UNDO or Redo algorithm)
Disadvantages:
1. Commit overhead.
2. Data fragmentation.
 Locality property is lost: shadow pages causes database pages to
change location
3. Garbage collection
 When transaction commits, database pages containing old version of
data changed by transaction become inaccessible.