Database Management Systems

G. Sunil Reddy
CSE II Year - II Semester
School of CS & AI
SR University
 UNIT-IV
Transaction processing

• Transaction processing concepts, Schedules

and Serializability, Testing for Serializability,
Conflict Serializability, View Serializability.

www.company.com
G. Sunil Reddy Dept of CSE
 UNIT-IV
Transaction processing

• To understand what a transaction in DBMS is and it’s

properties.
• To understand the concept of cascade less
transactions
Objectives: • To understand the concept of Serializability
• To understand the concept of Conflict Serializability
• To understand the concept of View Serializability

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
1. Transaction Definition
2. Transactions operations: Read and Write Operations
3. Granularity:
4. Transaction States or State Transition Diagram
Operations
Topics: i. Active state
ii. Partially committed state
iii. Committed state
iv. Failed state
v. Terminated state
5. ACID Properties
i. Atomicity
ii. Consistency
iii. Isolation
iv. Durability

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
6. The System Log
7. Concurrency Control Definition
8. Why Concurrency Control Is Needed
i. Lost update problem
ii. The temporary update or Dirty Read Problem.
Topics: iii. Incorrect summary problem
9.Types of Failures
i. A computer failure (system crash):
ii. A transaction or system error:
iii.Local errors or exception conditions detected by the
transaction:
iv. Concurrency control enforcement:
v. Disk failure:
vi. Physical problems and catastrophes:

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
10. Schedule
11. Schedules (Histories) of Transactions
12. Characterizing Schedules Based on Recoverability
i. Recoverable schedule
ii. Cascadeless schedule
iii. Strict schedule
13. Schedules classified on Serializability
Topics: • Serializable schedule
i. Result equivalent
ii. Conflict equivalent
iii. Conflict serializable

www.company.com
G. Sunil Reddy Dept of CSE
 Single User Vs. Multi User Systems:
• A DBMS is a single user if at most one user at a time
can use the system
Topic 1 • A DBMS is a multi user if many users can use the
system and hence access the database concurrently
Introduction to • Multiple users can access databases and use the
Transaction computer systems simultaneously because of the
Processing concept of Multiprogramming

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction:
What is Transaction?
• A transaction is a unit of work that is performed against
Topic 1 a database.
• A transaction is a unit of program execution that
Introduction to accesses the database and possibly updates
Transaction various data items in the database.
Processing
• A transaction is an action, or series of actions,
carried out by user or application, which accesses
or updates contents of database.

Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction:
• A transaction includes one or more database
access operations - these can include
Topic 1 insertion, deletion, modification, or retrieval
operations.
Introduction to
Transaction • The database operations that form a
Processing transaction can either be embedded within an
application program or they can be specified
interactively via a high-level query language
such as SQL.

Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction:
• One way of specifying the transaction
boundaries is by specifying explicit begin
Topic 1 transaction and end transaction
Introduction to statements in an application program
Transaction • In this case, all database access
Processing
operations between the two are
considered as forming one transaction
• A single application program may contain
more than one transaction if it contains
several transaction boundaries
Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction:
• Transaction is a single unit of work
Topic 1 • If a transaction is successful, all of the
data modifications made during the
Introduction to transaction are committed and become
Transaction
Processing a permanent part of the database
• If a transaction encounters errors and
must be canceled or rolled back, then
all of the data modifications are erased

Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction:
BEGIN TRANSACTION
Topic 1 Update account set bal =bal+50 where
acc_no=697;
Introduction to
Transaction
COMMIT TRANSACTION;
Processing END TRANSACTION

Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction processing systems
• Transaction processing systems are systems with
large databases and hundreds of concurrent
Topic 1 users that are executing database transactions.

Introduction to
• Examples of such systems are
Transaction • reservations
Processing • banking,
• stock markets,
• super markets,
• and other similar systems
• They require high availability and fast response
time for hundreds of concurrent users
Transaction Basics
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction Basics
read-only transaction:
Topic 1 • If the database operations in a transaction do
not update the database but Only retrieve
Introduction to data, the transaction is called a read-only
Transaction transaction.
Processing
• A database is basically represented as a
collection of named data items.
Granularity:
• The size of a data item is called its
granularity, and it can be a field of some
record in the database.

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction Basics
Basic database access operations:
read_item(X):
Topic 1
• Reads a database item named X into a program
variable.
Introduction to
Transaction • To simplify our notation, we assume that the
Processing program variable is also named X.
write_item(X):
• Writes the value of program variable X into the
database item named X.

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction Basics
READ AND WRITE OPERATIONS:
• Basic unit of data transfer from the disk to the
Topic 1 computer main memory is one block.
read_item(X) command includes the following
Introduction to steps:
Transaction 1. Find the address of the disk block that contains
Processing item X.
2. Copy that disk block into a buffer in main memory
(if that disk block is not already in some main
memory buffer).
3. Copy item X from the buffer to the program
variable named X.

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction Basics
READ AND WRITE OPERATIONS (cont.):
write_item(X) command includes the following
Topic 1 steps:
1. Find the address of the disk block that
Introduction to contains item X.
Transaction
Processing
2. Copy that disk block into a buffer in main
memory (if that disk block is not already in
some main memory buffer).
3. Copy item X from the program variable
named X into its correct location in the buffer.
4. Store the updated block from the buffer back
to disk (either immediately or at some later
point in time).
Basic operations
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction Basics

Two sample transactions. (a) Transaction T1.

Topic 1 (b) Transaction T2.

Introduction to
Transaction
Processing

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction States or State Transition
Diagram

Topic 2

Transaction states:
• Active state
• Partially committed state
Transaction • Committed state
States • Failed state
• Terminated State

www.company.com
G. Sunil Reddy Dept of CSE
 Cont...

begin_transaction:
• This marks the beginning of transaction
Topic 2 execution.
end_transaction:
Transaction
States
• This specifies that read and write transaction
operations have ended and marks the end of
transaction execution
• At this point it may be necessary to check
whether the changes introduced by the
transaction can be permanently applied to the
database or whether the transaction has to be
aborted because it violates concurrency
control or for some other reason
www.company.com
G. Sunil Reddy Dept of CSE
 Transaction States or State Transition
Diagram
read or write:
Topic 2
• These specify read or write operations on the
database items that are executed as part of a
transaction
Transaction
States commit_transaction:
• This signals a successful end of the
transaction so that any changes (updates)
executed by the transaction can be safely
committed to the database and will not be
undone

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction States or State Transition
Diagram
Active state:
Topic 2
• A transaction goes into an active state
immediately after it starts execution, where it
Transaction can issue READ and WRITE operations
States Partially committed state:
• When the transaction ends, it moves to the
partially committed state

www.company.com
G. Sunil Reddy Dept of CSE
 Transaction States or State Transition
Diagram
Rollback (or abort):
Topic 2
• This signals that the transaction has ended
unsuccessfully, so that any changes or
effects that the transaction may have applied
Transaction
to the database must be undone
States
Failed state:
• A transaction can go to the failed state if one
of the checks fails or if the transaction is
aborted during its active state

www.company.com
G. Sunil Reddy Dept of CSE
 ACID properties or DESIRABLE
PROPERTIES OF TRANSACTIONS
• In DBMS ACID (Atomicity, Consistency,
Isolation and Durability) is a set of
Topic 3
properties that guarantee that database
ACID transactions are processed reliably
properties

www.company.com
G. Sunil Reddy Dept of CSE
 Atomicity:
• Atomicity refers to the ability of the
DBMS to guarantee that either all of the
Topic 3
operations of a transaction are
ACID performed or none of them are
properties • Database modifications must follow an
“all or nothing rule”
• The atomicity property requires that we
execute a transaction to completion
• It is the responsibility of the transaction
recovery subsystem of a DBMS to
ensure atomicity
www.company.com
G. Sunil Reddy Dept of CSE
 Atomicity: Example
• Let's assume that following transaction T consisting
of T1 and T2. A consists of Rs 600 and B consists of
Topic 3 Rs 300. Transfer Rs 100 from account A to account
B.
ACID T1 T2
properties Read(A) Read(B)
A:= A-100 Y:=Y+100
Write(A) Write(B)

• After completion of the transaction, A consists of Rs 500 and B consists

of Rs 400.
• If the transaction T fails after the completion of transaction T1 but before
completion of transaction T2, then the amount will be deducted from A but
not added to B. This shows the inconsistent database state. In order to
ensure correctness of database state, the transaction must be executed
in entirety.
www.company.com
G. Sunil Reddy Dept of CSE
 Consistency:
• Consistency means that data in
database will be consistent(accurate)
Topic 3
• A transaction is consistency preserving if
ACID its complete execution takes the
properties database from one consistent state to
another
• The consistency property ensures that
any transaction will bring the database
from one valid state to another
• Any data written to the database must be
valid according to all defined rules
www.company.com
G. Sunil Reddy Dept of CSE
 Consistency:
• The consistency property ensures that
the database remains in a consistent
Topic 3
state before the start of the transaction
ACID and after the transaction is over
properties (whether successful or not)
• The preservation of consistency is
generally considered to be the
responsibility of the programmers who
write the database programs or of the
DBMS module that enforces integrity
constraints
www.company.com
G. Sunil Reddy Dept of CSE
 Consistency:

Topic 3

ACID
properties
Example

www.company.com
G. Sunil Reddy Dept of CSE
 Consistency:
• In the above figure, there are three accounts, A, B, and C,
where A is making a transaction T one by one to both B &
Topic 3 C. There are two operations that take place, i.e., Debit and
Credit. Account A firstly debits $50 to account B, and the
amount in account A is read $300 by B before the
ACID transaction.
properties • After the successful transaction T, the available amount in
B becomes $150. Now, A debits $20 to account C, and that
time, the value read by C is $250 (that is correct as a debit
Example
of $50 has been successfully done to B).
• The debit and credit operation from account A to C has
been done successfully. We can see that the transaction is
done successfully, and the value is also read correctly.
Thus, the data is consistent.
• In case the value read by B and C is $300, which means
that data is inconsistent because when the debit operation
executes, it will not be consistent.
www.company.com
G. Sunil Reddy Dept of CSE
 Isolation:
• For every pair of transactions, one transaction
should start execution only when the other
Topic 3 finished execution
• That is, the execution of a transaction should
ACID not be interfered by any other transactions
properties executing concurrently
• 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
• Every transaction does not make its updates
visible to other transactions until it is committed
www.company.com
G. Sunil Reddy Dept of CSE
 Isolation:
• For example account A is having a balance of
100$ and it is transferring 20$ to account B & C
Topic 3 both
• So we have two transactions here
ACID • Let’s say these transactions run concurrently
properties and both the transactions read 100$ balance, in
that case the final balance of A would be 80$
Example
instead of 60$
• This is wrong. If the transaction were to run in
isolation then the second transaction would
have read the correct balance 80$

www.company.com
G. Sunil Reddy Dept of CSE
 Isolation:

Topic 3

ACID
properties
Example

• Account A is making T1 and T2 transactions

to account B and C, but both are executing
independently without affecting each other.
It is known as Isolation
www.company.com
G. Sunil Reddy Dept of CSE
 Durability:
• Once a transaction completes successfully, the
changes it has made into the database should be
Topic 3 permanent even if there is a system failure
• The recovery-management component of
ACID database systems ensures the durability of
properties transaction
• The changes applied to the database by a
committed transaction must persist in the database
• These changes must not be lost because of any
failure
• Maintaining updates of committed transactions is
critical
• These updates must never be lost

www.company.com
G. Sunil Reddy Dept of CSE
 Some important points

Responsibility for
Topic 3 Property
maintaining properties

ACID Atomicity Transaction Manager

properties
Consistency Application programmer

Isolation Concurrency Control Manager

Durability Recovery Manager

www.company.com
G. Sunil Reddy Dept of CSE
 Some important points

Topic 3

ACID
properties

www.company.com
G. Sunil Reddy Dept of CSE
 Implementation of Atomicity and Durability:
• The recovery management component of a database system
can support atomicity and durability by using a variety of
schemes, one such scheme is called “shadow-paging
technique”
Topic
• This scheme is based on making copies of the database called
“shadow-copies”, and assumes that only one transaction is
active at any given time
• It also assumes that the database is simply a file on the disk. A
pointer called ‘db_pointer’ is maintained on the disk, which
points to the current copy of the database
• In the shadow-copy technique, any transaction that wants to
update the database, first creates a complete copy of the
database. Then, all the updates are done on the new database
copy, leaving the shadow copy(original copy) untouched
• If, at any point of time, the transaction has to be aborted, the
system simply deletes the new copy and the old copy of the
database has not been effected
www.company.com
G. Sunil Reddy Dept of CSE
 Implementation of Atomicity and Durability:

Db_pointer Db_pointer
Old Copy of
Topic Old Copy of the Database New Copy
the (to be deleted) of the
Database Database
• If a transaction completes, then it is committed as follows,
1. First, the O.S is asked to make sure that all the pages of the
new copy of the database have been written to the disk
2. After the O.S has written all the pages to the disk, the database
system updates the db_pointer to point the new copy of the
database
3. The new copy then becomes the current copy of the database
4. The old copy of the database is then deleted
5. The transaction is said to be committed when the updated
db_pointer is written to the disk
www.company.com
G. Sunil Reddy Dept of CSE
 Implementation of Atomicity and Durability:

• So, if a system failure occurs before the

db_pointer is pointed to the new database, the
Topic system simply discards the new copy of the
database and the old copy is pointed by the
db_pointer upon restart
• If a system failure occurs after the db_pointer is
pointed to the new database, then the system
points to the new copy of the database and is
consistent

www.company.com
G. Sunil Reddy Dept of CSE
 Concurrency:
• Concurrency means allowing multiple users
to access the data in a database at the same
Topic 4 time
ACID • If concurrent access is not managed by the
properties Database Management System (DBMS) when
various transactions interleave, it results in an
inconsistent database
• The transactions are interleaved, means
second transaction is started before the first
one could end. And execution can switch
between the transactions back and forth

www.company.com
G. Sunil Reddy Dept of CSE
 Concurrency control:
• It is a process of managing simultaneous
operations on the database without having
Topic 4 interfere them with one another
Concurrency • Prevents interference when two or more users
control: are accessing database simultaneously and at
least one is updating data
• Although two transactions may be correct in
themselves, interleaving of operations may
produce an incorrect result

Introduction to
concurrency
control

www.company.com
G. Sunil Reddy Dept of CSE
 Why Concurrency Control Is Needed
• Transactions submitted by the various users
may execute concurrently and may access and
Topic 5 update the same database items
Why • If this concurrent execution is uncontrolled, it
Concurrency may lead to problems, such as an inconsistent
Control Is database
Needed
• Several problems can occur when concurrent
transactions execute in an uncontrolled
manner

www.company.com
G. Sunil Reddy Dept of CSE
 Why Concurrency Control Is Needed

These problems are

Topic 5 1. Lost update problem
2. The temporary update or Dirty Read
Why Problem
Concurrency
Control Is 3. Incorrect summary problem
Needed

Basics

www.company.com
G. Sunil Reddy Dept of CSE
 The Lost Update Problem
• This problem occurs when two transactions
that access and update the same database
Topic 5 items and their interleaved operations makes
the value of some database items incorrect.
Why
Concurrency • Suppose that transactions T1 and T2 are
Control Is submitted at approximately the same time, and
Needed suppose that their operations are interleaved
as shown in the figure a, then the final value of
X is incorrect.
• Because T2 reads the value of X before T1
changes it in the database and hence the
updated value resulting from T1 is lost.
www.company.com
G. Sunil Reddy Dept of CSE
 The Lost Update Problem

Topic 5

Why
Concurrency
Control Is
Needed

www.company.com
G. Sunil Reddy Dept of CSE
 The Temporary Update (or Dirty Read)
Problem
• This problem occurs when one transaction
updates a database item and then the
Topic 5
transaction fails for some reason
Why • The updated item is accessed by another
Concurrency transaction before it is changed back to its
Control Is
Needed original value
• Figure shows an example where T1
updates item X and then fails before
completion, so the system must change X
back to its original value

www.company.com
G. Sunil Reddy Dept of CSE
 The Temporary Update (or Dirty Read)
Problem
• Before it can do so, however, transaction
T2 reads the temporary value of X, which
Topic 5
will not be recorded permanently in the
Why database because of the failure of T .
Concurrency
Control Is
• The value of item X that is read by T2 is
Needed called dirty data, because it has been
created by a transaction that has not
completed and committed yet; hence, this
problem is also known as the dirty read
problem.

www.company.com
G. Sunil Reddy Dept of CSE
 The Temporary Update (or Dirty Read)
Problem

Topic 5

Why
Concurrency
Control Is
Needed

www.company.com
G. Sunil Reddy Dept of CSE
 The Incorrect Summary Problem

• If one transaction is calculating an

aggregate summary function on a number
Topic 5
of records while other transactions are
Why updating some of these records, the
Concurrency aggregate function may calculate some
Control Is
values before they are updated .
Needed
• For example, suppose that a transaction T3
is calculating the total number of
reservations on all the flights; meanwhile,
transaction T1is executing.

www.company.com
G. Sunil Reddy Dept of CSE
 The Incorrect Summary Problem

• If the interleaving of operations shown in

Figure occurs, the result of T3 will be off by
Topic 5
an amount N because T3 reads the value
Why of X after N seats have been Subtracted
Concurrency from it but reads the value of Y before
Control Is
those N seats have been added to it.
Needed

www.company.com
G. Sunil Reddy Dept of CSE
 The Incorrect Summary Problem

•
Topic 5

Why
Concurrency
Control Is
Needed

www.company.com
G. Sunil Reddy Dept of CSE
 Concurrent Executions:
• The advantages of allowing concurrent
execution of transactions are:
Topic 6
• Improved throughput and resource utilization
Concurrency • Reduced waiting time
control:

Introduction to
concurrency
control

www.company.com
G. Sunil Reddy Dept of CSE
 Schedule

• When transactions are executing concurrently

in an interleaved fashion, then the order of
Topic 7 execution of operations from the various
transactions is known as a schedule.
Schedule
• A schedule is a process of grouping the
transactions into one and executing them in a
predefined order

Schedules

www.company.com
G. Sunil Reddy Dept of CSE
 Schedules of Transactions
• For example, consider transaction T1 transferring
Rs. 100 from account A to account B and consider
Topic 7 transaction T2 transfers half of the remaining
balance in account A to account C
Schedule
T1: read(A) T2: read(A)
A:= A-100; temp:= A*0.5;
write(A) A:= A-temp
read(B) write(A)
B:= B+100; read(C)
write(B) C:= C+temp;
write(C)

www.company.com
G. Sunil Reddy Dept of CSE
 Schedules of Transactions
• A schedule represents the chronological order in which the
transactions are executed. So, if T1 and T2 are scheduled
serially to execute T1 first and then T2. Then schedule ‘S’ looks
Topic 7 like:
T1: T2:
read(A)
Schedule A:= A-100;
write(A)
read(B)
B:= B+100;
write(B)
------------------------------------ -------------------------------------
read(A)
temp:= A*0.5;
A:= A-temp
write(A)
read(C)
C:= C+temp;
write(C)
www.company.com
G. Sunil Reddy Dept of CSE
 Schedules of Transactions
• Now a concurrent execution of the same transactions may look
like the following schedule:
Topic 7 T1: T2:
read(A)
A:= A-100;
Schedule write(A)
----------------------------------- -----------------------------------
read(A)
temp:= A*0.5;
A:= A-temp
write(A)
----------------------------------- -----------------------------------
read(B)
B:= B+100;
write(B)
----------------------------------- -----------------------------------
read(C)
C:= C+temp;
write(C)

www.company.com
G. Sunil Reddy Dept of CSE
 Serializability
• The two most important operations that a transaction
perform are read() and write(), the concurrent execution
of T1 and T2 can simply be shown as the following
Topic 7 serializable schedule ‘S’:

Schedule T1: T2:

read(A)
write(A)
-----------------------------------
-----------------------------------
read(A)
write(A)
-----------------------------------
-----------------------------------
read(B)
write(B)
----------------------------------- -----------------------------------
read(B)
write(B)

www.company.com
G. Sunil Reddy Dept of CSE
 Serializability
• The two different forms of schedule
equivalence include:
Topic 7 • Conflict Serializability
Schedule
• View Serializability

www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability:
• Let us consider that in a schedule ‘S’, there
are two consecutive instructions Ii and Ij of
Topic 7 transactions Ti and Tj respectively (where i
Schedule
is not equal to j) then,
• If, Ii and Ij refer to different data items then
they are called as non conflicting
instructions and we can simply swap Ii and
Ij without effecting the results of the
schedule.

www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability:
• But if Ii and Ij refer to a same data item ‘Q’, then we
will have the following four cases:
Topic 7 1. Ii = read(Q) and Ij = read(Q), then the order of Ii
and Ij does not conflict since the same value of ‘Q’
Schedule is read by Ti and Tj
2. Ii = read(Q) and Ij = write(Q), then the order of Ii
and Ij is important and may result in a conflict in
reading the value of ‘Q’
3. Ii = write(Q) and Ij = read(Q), then the order of Ii
and Ij is important and may result in a conflict in
reading the value of ‘Q’
4. Ii = write(Q) and Ij = write(Q), then the order of Ii and Ij is
not important but the next read operation in the
schedule may result in a conflict value of ‘Q’
www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability:
• Two operations in a schedule are said to
conflicting if they satisfy all three of the
Topic 7 following conditions:
Schedule 1. They belong to different transactions;
2. They access the same item Q; and
3. At least one of the operations is a
write_item(Q)

www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability
• Now, if a pair of non conflicting instructions are
swapped in schedule ‘S’ to form a new
Topic 7 schedule ‘S1’, as shown:
T1: T2:
Schedule read(A)
write(A)
----------------------------------- -----------------------------------
read(A)
----------------------------------- -----------------------------------
read(B)
----------------------------------- -----------------------------------
write(A)
----------------------------------- -----------------------------------
write(B)
----------------------------------- -----------------------------------
read(B)
write(B)

www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability
• If a schedule ‘S’ can be transformed into a
schedule ‘S1’ by a series of swaps of non-
Topic 7 conflicting instructions, then we say that ‘S’
Schedule
and ‘S1’ are “conflict equivalent”
• We say that a schedule ‘S’ is “conflict
serializable” if it is conflict equivalent to a
serial schedule
Note:
• If a write(Q) operation is performed without
having performed read(Q) operation, then
such writes are called “blind writes”
www.company.com
G. Sunil Reddy Dept of CSE
 Conflict Serializability
• If a schedule ‘S’ can be transformed into a
schedule ‘S1’ by a series of swaps of non-
Topic 7 conflicting instructions, then we say that ‘S’
Schedule
and ‘S1’ are “conflict equivalent”
• We say that a schedule ‘S’ is “conflict
serializable” if it is conflict equivalent to a
serial schedule
Note:
• If a write(Q) operation is performed without
having performed read(Q) operation, then
such writes are called “blind writes”
www.company.com
G. Sunil Reddy Dept of CSE
 View Serializability
• Two schedules ‘S’ and ‘S1’ are said to be view
equivalent if the following three conditions hold:
1. For each data item ‘Q’, if transaction T1 reads
Topic 8 the initial value of ‘Q’ in schedule ‘S’, then
transaction T1 must also read the initial value of
‘Q’ in schedule ‘S1’
2. For each data item ‘Q’, if transaction T2
executes read(Q) operation in schedule ‘S’ and
if that value is produced by write(Q) operation of
T1 then, the read(Q) operation of transaction T2
must also read the value of ‘Q’ that was
produced by the same write(Q) operation of T1
in schedule ‘S1’
3. For each data item ‘Q’, the transaction that
performs the final write(Q) operation in schedule
‘S’, must also perform the final write(Q)
operation in schedule ‘S1’
www.company.com
G. Sunil Reddy Dept of CSE
 View Serializability
• Two schedules ‘S’ and ‘S1’ are said to be view
equivalent if the following three conditions hold:
1. For each data item ‘Q’, if transaction T1 reads
Topic 8 the initial value of ‘Q’ in schedule ‘S’, then
transaction T1 must also read the initial value of
‘Q’ in schedule ‘S1’
2. For each data item ‘Q’, if transaction T2
executes read(Q) operation in schedule ‘S’ and
if that value is produced by write(Q) operation of
T1 then, the read(Q) operation of transaction T2
must also read the value of ‘Q’ that was
produced by the same write(Q) operation of T1
in schedule ‘S1’
3. For each data item ‘Q’, the transaction that
performs the final write(Q) operation in schedule
‘S’, must also perform the final write(Q)
operation in schedule ‘S1’
www.company.com
G. Sunil Reddy Dept of CSE
 View Serializability
• A schedule ‘S’ is said to be view
serializable if it is view equivalent to a
Topic 8 serial schedule
T1: T2:
read(A)
write(A)
----------------------------------- -----------------------------------
read(A)
----------------------------------- -----------------------------------
read(B)
----------------------------------- -----------------------------------
write(A)
----------------------------------- -----------------------------------
write(B)
----------------------------------- -----------------------------------
read(B)
write(B)

www.company.com
G. Sunil Reddy Dept of CSE
www.company.com
 Recoverability
• If a transaction T1 fails, we need to undo
the effect of this transaction to ensure
Topic 9 atomicity
Recoverability • So, in a system that allows concurrent
execution of transactions, it is also
necessary to ensure that any other
transaction T2 that is dependent on T1 is
also aborted if T1 is aborted

www.company.com
G. Sunil Reddy Dept of CSE
 Characterizing Schedules Based on
Recoverability
• For some schedules it is easy to recover
from transaction failures, whereas for other
Topic 10 schedules the recovery process can be
Characterizing
quite involved.
Schedules • Following are the schedules classified
Based on based on recoverability
Recoverability
1.Recoverable schedule
2.Cascadeless schedule
3.Strict schedules

Types of schedule
www.company.com
G. Sunil Reddy Dept of CSE
 Recoverable schedules
• A schedule S is recoverable if it satisfies
the following two conditions:
Topic 10 1. Ti reads ‘Q’ previously written by Tj
Characterizing
2. Tj commits before Ti commits.
Schedules • A recoverable schedule is one where, for
Based on each pair of Transaction Ti and Tj such that
Recoverability
Ti reads data item previously written by Tj
then the commit operation of Tj appears
before the commit operation Ti

www.company.com
G. Sunil Reddy Dept of CSE
 Recoverable schedules

T1: T2:
read(A)
Topic 10 write(A)
----------------------------------- -----------------------------------
read(A)
Characterizing ----------------------------------- -----------------------------------
read(B)
Schedules Commit
Based on ----------------------------------- -----------------------------------
Recoverability commit

• From the above example, to make it a

recoverable schedule, T1 should commit
before T2 is committed, since Transaction
T2 is reading a value that is written by T1

www.company.com
G. Sunil Reddy Dept of CSE
 Cascadeless schedule
• A schedule is said to be cascadeless, if every
transaction in the schedule reads only items
Topic 10 that were written by committed transactions.
T1: T2: T3:
Characterizing read(A)
Schedules write(A)
Based on --------------------------- --------------------------------- --------------------------
read(A)
Recoverability Write(A)
--------------------------- --------------------------------- --------------------------
Read(A)

• In the above example, to make it a

cascadeless schedule, T1 should be
committed before and T2 reads ‘A’ should be
committed before T3 reads ‘A’.
www.company.com
G. Sunil Reddy Dept of CSE
 Strict schedules
• A schedule, called a strict schedule, in which
transactions can neither read nor write an item
Topic 10 X until the last transaction that wrote X has
committed (or aborted). Strict schedules
Characterizing simplify the recovery process.
Schedules
Based on
T1 T2
Recoverability
Read(A)
Write(A)
Commit;
------------------- --------------------
Read(A)
Write(A)
Commit;

www.company.com
G. Sunil Reddy Dept of CSE
 Testing for Serializability
• When designing concurrency control schemes, we must
ensure that the schedules generated by the scheme are
Topic 11 serializable. A simple method to determine conflict
Serializability is to construct a ‘precedence graph’

Characterizing
• For a schedule ‘S’, the precedence graph consists of a
pair G=(V, E) where ‘V’ is set of vertices that consists of
Schedules
all transactions and ‘E’ is set of all the edges
based on
Serializability • So, if an edge Ti  Tj exists in the precedence graph
then, in any serial schedule ‘S’, Ti must appear before
Tj
T1 T2
Read(A) T1 T2
Write(A)
---------------- -----------------
Read(A)
Write(A)

www.company.com
G. Sunil Reddy Dept of CSE
 Implementation of Isolation
• Even with multiple transactions executing
concurrently, there are many schemes that can be
Topic 12 used to ensure that only acceptable schedules are
generated
Characterizing • One such scheme of implementing isolation
Schedules involves in a transaction acquiring a lock on the
based on entire database before the transaction starts and
Serializability releases the lock after the transaction commits
• When a transaction holds a lock on the database,
no other transaction is allowed to acquire a lock on
it and must wait until the lock is released
• As a result of this locking policy, only one
transaction can execute at one time and isolation
is implemented
www.company.com
G. Sunil Reddy Dept of CSE
 THANK YOU

www.company.com
G. Sunil Reddy Dept of CSE
Database Management Systems

G. Sunil Reddy
CSE II Year - II Semester
School of CS & AI
SR University
 UNIT-IV Part-2
Concurrency Control Protocols

• Concurrency control, Lock –Based Protocols

– Timestamp Based Protocols - Validation-
Based Protocols.
• Recovery and Atomicity – Log - Based
Recovery – Recovery with Concurrent
Transactions – Buffer Management.

www.company.com
G. Sunil Reddy Dept of CSE
 UNIT-IV
Concurrency Control Protocols

• To understand the concept of Conflict Operations that

happen among multiple transactions executed
concurrently and how to resolve such conflicts when
multiple transactions are executing parallelly and all
the transactions are accessing the common data
Objectives:
• To understand Different schedule algorithms and
protocols.
• To understand the concept of Database Recovery
techniques.

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
1. Purpose of Concurrency Control
2. LOCK
Definition:
Types of Locks
i. Binary Locks
ii. Shared/Exclusive ( Read/Write) Locks

Topics:

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
3. Concurrency Control Techniques
1) Locking Techniques for Concurrency Control
– Two-Phase Locking Techniques
i. BASIC
ii. CONSERVATIVE
iii. STRICT

Topics: iv. RIGOUROUS

2) Concurrency Control Techniques Based on Timestamp
Ordering
i. Basic Timestamp Ordering
ii. Strict Timestamp Ordering
3) Concurrency Control Techniques Based on Validation

www.company.com
G. Sunil Reddy Dept of CSE
 Contents
4. Dead Locks
– Deadlock Prevention
i. Wait-die
ii. wound-wait schemes
– Deadlock Detection
i. Wait-for graph

Topics: ii. Timeouts

– Starvation
5. Recovery Concepts
• Write-Ahead Logging
• Shadow paging
• ARIES recovery algorithm

www.company.com
G. Sunil Reddy Dept of CSE
 Purpose of Concurrency Control
In a multiprogramming environment where
multiple transactions can be executed
Topic 1 simultaneously, it is highly important to control the
concurrency of transactions
Purpose of 1.To enforce Isolation among conflicting
Concurrency transactions
Control 2.To preserve database consistency
3.To resolve read-write, write-read and write-write
conflicts

www.company.com
G. Sunil Reddy Dept of CSE
 Concurrency Control Techniques
1) Concurrency Control Techniques Based
on locks: Two-Phase Locking Techniques
Topic 1 i. BASIC
ii. CONSERVATIVE
Purpose of
Concurrency
iii. STRICT
Control iv. RIGOUROUS
2) Concurrency Control Techniques Based
on Timestamp Ordering
i. Basic Timestamp Ordering
ii. Strict Timestamp Ordering
3) Concurrency Control Techniques Based
on Validation

www.company.com
G. Sunil Reddy Dept of CSE
 Locking Techniques for Concurrency
Control – Lock based protocols:
• Some of the main techniques used to
control concurrent execution of transactions
Topic 2 are based on the concept of locking data
items
LOCK
• Definition : Lock is a variable associated
with data item which gives the status
whether the operations can be applied on
it or not
• Any transaction cannot read or write data
until it acquires an appropriate lock on it

www.company.com
G. Sunil Reddy Dept of CSE
 Locking Techniques for Concurrency
Control – Lock based protocols
Locking is an operation which secures permission
to Read or to Write a data item for a transaction.
Topic 2 Example: Lock (X)
Data item X is locked in behalf of the requesting
Locking transaction.
Techniques
Unlocking is an operation which removes these
for permissions from the data item.
Concurrency
Example: Unlock (X)
Control
Data item X is made available to all other
transactions.
The DBMS has a lock manager subsystem to keep
track of and control access to locks.
www.company.com
G. Sunil Reddy Dept of CSE
 Types of Locks
1. A binary lock
2. Shared/exclusive locks
Topic 3
A binary lock:
Binary Lock • A binary lock can have two states or
values: locked and unlocked (or 1 and 0,
for simplicity).
• If the value of the lock on X is 1, item 'X
cannot be accessed by a database
operation that requests the item.
• If the value of the lock on X is 0, the item
can be accessed when requested.
www.company.com
G. Sunil Reddy Dept of CSE
 Types of Locks
• Two operations, lock_item and
unlock_item, are used with binary locking
3
•
Topic
A transaction requests access to an item X
Binary Lock by first issuing a lock_item(X) operation
• When the transaction is through using the
item, it issues an unlock_item(X) operation,
which sets LOCK(X) to 0(unlocks the item)
so that 'X may be accessed by other
transactions

www.company.com
G. Sunil Reddy Dept of CSE
 Shared/Exclusive (or Read/Write) Locks

• The preceding binary locking scheme is too

restrictive for database items, because at
Topic 3 most one transaction can hold a lock on a
given item
• Shared/Exclusive Locks allow several
transactions to access the same item X for
reading purposes only
• However, if a transaction is to write an item
X, it must have exclusive access to X
• For this purpose, a different type of lock
called a multiple mode lock is used
www.company.com
G. Sunil Reddy Dept of CSE
 Shared/Exclusive (or Read/Write) Locks

• In this scheme-there are three locking

operations: read_lock(X), write_lock(X),
Topic 3 and unlock(X)
• A read-locked item is also called share-
locked, because other transactions are
allowed to read the item, whereas a write-
locked item is called exclusive-locked,
because a single transaction exclusively
holds the lock on the item

www.company.com
G. Sunil Reddy Dept of CSE
 Conversion of Locks
• It is possible for a transaction T to issue a
read_lock(X) and then later on to upgrade
Topic 3 the lock by issuing a write_lock(X)
operation
• It is also possible for a transaction T to
issue a write_lock(X) first and then later on
to downgrade the lock by issuing a
read_lock(X) operation

www.company.com
G. Sunil Reddy Dept of CSE
 Two-Phase Locking Protocol (2PL):
This protocol requires that each transaction
issues a lock and unlock requests in two
Topic 4 phases:
(a) Growing (first) or Expanding phase
Two-Phase (b) Shrinking phase
Locking
Techniques
Growing Phase:
• During which a transaction may acquire new
locks on items but none can be released;
Shrinking Phase:
• During which existing locks can be released
but no new locks can be acquired

www.company.com
G. Sunil Reddy Dept of CSE
 Two-Phase Locking Protocol:

Topic 4

Two-Phase
Locking • Initially a transaction is in a growing phase (lock
acquisition phase) and acquires locks as needed.
Techniques
Once the transaction releases a lock it enters into
shrinking phase and it cannot issue any more lock
requests
• The point in the schedule where the transaction has
obtained its final lock is called as ‘lock point’ of the
transaction.

www.company.com
G. Sunil Reddy Dept of CSE
 Two-Phase locking algorithms
Several variants of two phase locking
protocol include:
Topic 4
1. BASIC
Two-Phase 2. CONSERVATIVE
Locking 3. STRICT
Techniques 4. RIGOUROUS

www.company.com
G. Sunil Reddy Dept of CSE
 Basic 2PL:
Transaction divided into 2 phases:
Topic 4
• growing - new locks acquired but none
released
Two-Phase • Upgrading is ok
Locking • Shrinking - existing locks released but no
Techniques new ones acquired
• During the shrinking phase no new locks
can be acquired!
• Downgrading is ok
• Upgrading is not
www.company.com
G. Sunil Reddy Dept of CSE
 Conservative 2PL :
• A variation known as conservative 2PL
requires a transaction to lock all the items it
Topic 4 accesses before the transaction begins
execution
Two-Phase • It is predeclaring its readset and write-set
Locking
Techniques
• The read-set of a transaction is the set of all
items that the transaction reads, and the write-
set is the set of all items that it writes..
• If any of the items in read or write set is already
locked (by other transactions), transaction
waits (does not acquire any locks)
• Deadlock free but not very realistic
www.company.com
G. Sunil Reddy Dept of CSE
 Strict 2PL:
• A transaction T does not release any of its
exclusive (write) locks until after it commits
Topic 4 or aborts
Two-Phase • Hence, no other transaction can read or
Locking write an item that is written by T unless T
Techniques has committed
• Strict 2PL is not deadlock-free
• Most popular variation of 2PL

www.company.com
G. Sunil Reddy Dept of CSE
 Rigorous 2PL
• A more restrictive variation of strict 2PL is
rigorous 2PL, which also guarantees strict
Topic 4 schedules
Two-Phase • In this variation, a transaction T does not
Locking release any of its locks (exclusive or
Techniques shared) until after it commits or aborts

www.company.com
G. Sunil Reddy Dept of CSE
 Timestamp based protocol:
Timestamp
• Timestamp is a unique identifier created by
Topic 5 the DBMS to identify a transaction
Timestamp • Typically, timestamp values are assigned in
based the order in which the transactions are
concurrency submitted to the system, so a timestamp can
control
algorithm
be thought of as the transaction start time.
• It indicates the age of an operation or a
transaction.
Timestamp • We will refer to the timestamp of transaction
based Ti as TS(Ti).

www.company.com
G. Sunil Reddy Dept of CSE
 Timestamp based protocol:
• Concurrency control techniques based on
timestamp ordering do not use locks;
Topic 5 hence, deadlocks cannot occur
Timestamp • The idea for this scheme is to order the
based transactions based on their timestamps
concurrency
control • Any conflicting read/write operations are
algorithm executed in their timestamp order

Timestamp
based
www.company.com
G. Sunil Reddy Dept of CSE
 The Timestamp Ordering Algorithm
• The algorithm associates with each
database item Q two TimeStamp (TS)
Topic 5 values:
Timestamp • R_TimeStamp(Q): It denotes the largest
based timestamp of any transaction that executed
concurrency Read(Q) successfully.
control
algorithm • W_TimeStamp(Q): It denotes the largest
timestamp of any transaction that executed
Write(Q) successfully
Timestamp • The above timestamps are updated
based whenever a new read(Q) or write(Q)
instruction is executed
www.company.com
G. Sunil Reddy Dept of CSE
 Basic Timestamp Ordering
1. Transaction Ti issues a read_item(Q) operation:
If (TS(Ti) < W_Timestamp(Q))
Topic 5 abort and roll-back Ti and reject the operation.
else {
read_item(Q)
Timestamp R_TimeStamp(Q) = TS(Ti)
based }
concurrency 2. Transaction Ti issues a write_item(Q) operation:
control If (TS(T) < R_TimeStamp(Q) or (TS(T) <
algorithm W_TimeStamp(Q))
abort and roll-back Ti and reject the operation
else {
write_item(Q)
W_TimeStamp(Q) =TS(Ti)
}
www.company.com
G. Sunil Reddy Dept of CSE
 Validation based protocol:
• In this protocol, we assume that each transaction
executes in three different phases in its life time,
Topic 6 as shown
1. Read Phase: During this phase, the system
Validation executes transaction Ti. It reads the values of
based various data items and stores them in the local
concurrency
buffer of Ti. It performs all the write operations on
control
algorithm
the local buffer without updating the actual
database.
2. Validation Phase: The transaction Ti performs a
validation test to determine whether it can copy
Validation the results of write operation from the local buffer
based to the actual database without causing a violation
of Serializability
www.company.com
G. Sunil Reddy Dept of CSE
 Validation based protocol:
3. Write Phase: If the transaction Ti succeeds in
the above validation phase, then the system
Topic 6 applies the actual updates on the database,
otherwise, the system simply rolls back.
Validation
based
• Now, we know that Ti goes through the above
concurrency three phases, it is associated with three
control different timestamps as shown
algorithm 1. Start(Ti): The time when Ti started its
execution
2. Validation(Ti): The time when Ti finished its
Validation read phase and started its validation phase
based 3. Finish(Ti): The time when Ti finished its write
www.company.com
phase
G. Sunil Reddy Dept of CSE
 RECOVERY MANAGEMENT

• Recovery from transaction failures usually

means that the database is restored to the
Topic 7 most recent consistent state just before the
time of failure
• To do this, the system must keep information
about the changes that were applied to data
items by the various transactions
• This information is typically kept in the
system log

www.company.com
G. Sunil Reddy Dept of CSE
 RECOVERY AND ATOMICITY
• Consider an example of transaction T1
transferring an amount of Rs. 100 from
Topic 8 account A to account B. The initial values of
A and B are Rs. 500 and Rs. 1000 respt’ly
• If the transaction fails after debiting from A
but hasn’t credited to account B, then the
system can invoke one of the two possible
recovery procedures:
1. Re-execute: A becomes Rs. 300 and B
becomes Rs. 1100 which is inconsistent
2. Do not Re-execute: A becomes Rs. 400
and B becomes Rs. 1000, which is
inconsistent too.
www.company.com
G. Sunil Reddy Dept of CSE
 RECOVERY AND ATOMICITY
• So, there are two possible ways to solve the
above problem:
Topic 8
1. Log-Based Recovery
2. Shadow Paging

www.company.com
G. Sunil Reddy Dept of CSE
 Log Based Recovery - The System Log

• To be able to recover from failures that affect

transactions, the system maintains a log
Topic 9
• A log is a sequence of log records, that records
all the update activities in the database
• The log is kept on disk, so it is not affected by
any type of failure except for disk or
catastrophic failure.
• In addition, the log is periodically backed up to
archival storage (tape) to guard against such
catastrophic failures.

www.company.com
G. Sunil Reddy Dept of CSE
 The System Log
Several types of log records include:
<Ti start>: Indicates that transaction Ti has started
Topic 9 execution.
<Ti, Xj, oldvalue, newvalue>: Indicates that
transaction Ti has changed the value of database item
Xj from old_value to new_value.
<Read, Ti, Xj>: Indicates that transaction Ti has read
the value of database item Xj.
<Ti commit>: Indicates that transaction Ti has
completed successfully, and affirms that its effect can
be committed (recorded permanently) to the
database.
<Ti abort>: Indicates that transaction Ti has been
aborted.
www.company.com
G. Sunil Reddy Dept of CSE
 Log Based Recovery

• The three techniques in log based recovery, in

order to ensure transaction atomicity despite
Topic 9 system failures are:

1. Deferred database modification

2. Immediate database modification
3. Checkpoints

www.company.com
G. Sunil Reddy Dept of CSE
 Deferred database modification
• The deferred update techniques do not
physically update the database on disk until
Topic 10 after a transaction reaches its commit point;
then the updates are recorded in the
database.
• Before reaching commit, all transaction
updates are recorded in the local
transaction workspace (or buffers).
• During commit, the updates are first
recorded persistently in the log and then
written to the database.

www.company.com
G. Sunil Reddy Dept of CSE
 Deferred database modification
• If a transaction fails before reaching its commit
point, it will not have changed the database in
Topic 10 any way, so UNDO is not needed
• For all those transactions which have <Ti start>
and <Ti commit> a REDO is applied
• REDO(Ti): It sets the values of all data items
updated by Ti to the new values. This
information is available in the log
• Hence, deferred update is also known as the
NO-UNDO/ REDO algorithm

www.company.com
G. Sunil Reddy Dept of CSE
 Deferred database modification
• Consider an example of T1 transfers Rs. 100 from
account A to B and T2 debited Rs. 100 from
Topic 10 account C, Initial amount of A, B and C are 1000,
5000, 6000 respect
Case 1 Case 2 Case 3
<T1 start> <T1 start> <T1 start>
<T1, A, 900> <T1, A, 900> <T1, A, 900>
<T1, B, 5100> <T1, B, 5100> <T1, B, 5100>
crash <T1 commit> <T1 commit>
<T2 start> <T2 start>
<T2, C, 5900> <T2, C, 5900>
crash <T2 commit>
crash
Nothing is done Redo(T1) is done Redo(T1) and
since <Ti commit> Redo(T2) is
is in log records performed
www.company.com
G. Sunil Reddy Dept of CSE
 Immediate database modification
• In the immediate database modification
technique, the database may be updated by
Topic 11 some operations of a transaction before the
transaction reaches its commit point
• However, these operations are typically
recorded in the log on disk by force writing
before they are applied to the database.
making recovery still possible
• If a transaction fails after recording some
changes in the database but before reaching
its commit point, the effect of its operations on
the database must be undone; that is, the
transaction must be rolled back
www.company.com
G. Sunil Reddy Dept of CSE
 Immediate database modification
• In the general case of immediate update,
both undo and redo may be required during
Topic 11 recovery
• This technique, known as the UNDO/REDO
algorithm, since it requires both operations,
and is used most often in practice
• All transactions that have <Ti start> but
doesn’t have <Ti commit> in the logrecord,
Undo(Ti) is applied and for all transactions
that have <Ti start> and <Ti commit> in the
logrecord, Redo(Ti) is applied

www.company.com
G. Sunil Reddy Dept of CSE
 Immediate database modification
• Consider an example of T1 transfers Rs. 100 from
account A to B and T2 debitd Rs. 100 from account
Topic 11 C, Initial amount of A, B and C are 1000, 5000,
6000 respect.
Case 1 Case 2 Case 3
<T1 start> <T1 start> <T1 start>
<T1, A, 1000, 900> <T1, A, 1000, 900> <T1, A, 1000, 900>
<T1, B, 5000, 5100> <T1, B, 5000, 5100> <T1, B, 5000, 5100>
crash <T1 commit> <T1 commit>
<T2 start> <T2 start>
<T2, C, 6000, 5900> <T2, C, 6000, 5900>
Crash <T2 commit>
Crash
Undo(T1) is Redo(T1) and Redo(T1) and
performed Undo(T2) is Redo(T2) is
performed performed

www.company.com
G. Sunil Reddy Dept of CSE
 Checkpoints
• In immediate and deferred database
modifications, when system failure occurs then
Topic 12 the entire log has to be checked to determine
the transactions to be undone and redone. This
process is time consuming and many
transactions may even be redone. Which is a
disadvantage
• A checkpoint will help reduce the above
disadvantages
• A checkpoint is periodically performed by the
system, and when it is performed, the following
sequence of actions take place

www.company.com
G. Sunil Reddy Dept of CSE
 Checkpoints
1. All the log records currently residing in the
main memory should be moved to a stable
Topic 12 storage
2. All modified buffer blocks should be moved
to the disk
3. A log record <checkpoint> should be
moved to the stable storage.
• Any transaction is not allowed to perform
any update action while a checkpoint is in
progress

www.company.com
G. Sunil Reddy Dept of CSE
 Checkpoints
• If a log record <checkpoint> is present in
the log then the system does its recovery
Topic 12 process as follows:
1. After a failure has occurred, the recovery
scheme examines the log to determine the
most recent transaction Ti that started
executing before the last checkpoint in the
log
2. To find such transaction, the log is
searched backwards from the end of log
until it finds the first <checkpoint> record
from the end
www.company.com
G. Sunil Reddy Dept of CSE
 Checkpoints
3. After finding <checkpoint> record, it still
keeps searching backwards until the first
Topic 12 <Ti start> record is found (search
backwards)
4. Once Ti is identified, either Undo or Redo
operations are applied on all transactions
executed after that <Ti start>
5. For all transactions executed after that <Ti
start> and has <Tk start> and doesn’t have
<Tk commit> log records, Undo is executed
6. For all transactions that has <Tk start> and
<Tk commit> log records, Redo is executed
www.company.com
G. Sunil Reddy Dept of CSE
 Recovery with Concurrent Transactions
• Almost similar to checkpoints, but since
multiple transactions will be active because
Topic 13 of concurrent execution of transactions, the
checkpoint will be of the form <checkpoint
L> where, ‘L’ is the list of transactions
active at the time of checkpoint.
• In concurrent execution, after a system
recovers from crash, it will construct two
lists of transactions
1. An ‘Undo’ list
2. A ‘Redo’ list
www.company.com
G. Sunil Reddy Dept of CSE
 Recovery with Concurrent Transactions
• These two lists are constructed as follows
1. For each log record that has <commit> is added
Topic 13 to the Redo list
2. For each log record that doesn’t have <commit>
is added to the Undo list
• Once a Redo and Undo list is constructed, then
the system recovery process is:
1. The system rescans the log backwards and
performs Undo for all transactions that belong to
the undo list ignoring all the redo records
2. Now, the system scans forward from checkpoint
and performs redo for all transactions that belong
to redo list ignoring all undo records
www.company.com
G. Sunil Reddy Dept of CSE
 Buffer Management

Topic 14
• It deals with
1. Log-record buffering
2. Database buffering

www.company.com
G. Sunil Reddy Dept of CSE
 Log Record Buffering
• Since we already know that all the log records
created must be moved to stable storage, so
Topic 14 that we don’t loose them if a system crashes.
This movement happens in blocks of memory
• As the size of the log record is much smaller
than a block, it is desirable to move multiple
log records to stable storage at once as a
block
• So, multiple log records can be gathered in
the log buffer and can be moved to the stable
storage in single output operation. The order
in the stable storage and in log buffer should
be exactly same
www.company.com
G. Sunil Reddy Dept of CSE
 Log Record Buffering
• So, the log records may reside in main
memory for some time before they are
Topic 14 moved to stable storage. If a system crashes
before the log records are moved to stable
storage, the records will be lost.
• So, some requirements are imposed on
recovery techniques to ensure atomicity, they
are:
1. Transaction Ti enters the commit state only
after <Ti commit> log record is moved to
stable storage

www.company.com
G. Sunil Reddy Dept of CSE
 Log Record Buffering
2. Before a <Ti commit> record can be moved
to stable storage all the log records
Topic 14 pertaining to Ti must have already been
moved to stable storage
3. Before a block of data in main memory can
be moved to database, all the log records
pertaining to data in that block must have
been moved to stable storage. This rule is
called “Write Ahead Logging (WAL)”

www.company.com
G. Sunil Reddy Dept of CSE
 Database Buffering
•The rules for moving the log records can limit
the freedom of the system to move the blocks
Topic 15 of data
• For eg. If the input of block B2 causes block
B1 to be chosen for output, then all the log
records pertaining to data in B1 must be
output to stable storage before B1 is output.
So the sequence of actions by the system are:
1. Output log records to stable storage until all
log records pertaining to a block B1 has been
output
2. Output block B1 to disk
3. Input block B2 from disk to main memory
www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm(Algorithm for
Recovery and Isolation Exploiting Semantics)
• ARIES uses a steal/no-force approach
for writing.
Topic 17
• The ARIES recovery procedure consists
The ARIES of three main steps or phases
(1) Analysis
(2) REDO
(3) UNDO

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• The analysis step identifies the dirty
(updated) pages in the buffer and the set of
Topic 17 transactions active at the time of the crash.
The ARIES • The appropriate point in the log where the
REDO operation should start is also
determined.
• The REDO phase actually reapplies
updates from the log to the database.
• Generally, the REDO operation is applied
to only committed transactions.

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• Finally, during the UNDO phase, the log is
scanned backwards and the operations of
Topic 17 transactions that were active at the time of
the crash are undone in reverse order.
The ARIES

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• The information needed for ARIES to
accomplish its recovery procedure includes
Topic 17 the log, the Transaction Table, and the Dirty
Page Table.
The ARIES
• These two tables are maintained by the
transaction manager.
• In ARIES, every log record has an associated
log sequence number (LSN) that is
monotonically increasing and indicates the
address of the log record on disk.
• Each LSN corresponds to a specific action of
some transaction.
www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• A log record is written for any of the
following actions:
17
•
Topic
Update, commit, abort, undo, and ending a
Log, transaction (end)
Transaction
& Dirty Page
Table

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• The Transaction Table contains an entry for
each active transaction, with information
Topic 17 such as the transaction ID, transaction
status, and the LSN of the most recent log
Log,
Transaction record for the transaction.
& Dirty Page
Table

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• The Dirty Page Table contains an entry for
each dirty page in the buffer, which
Topic 17 includes the PAGE ID and the LSN
corresponding to the earliest update to that
Log,
Transaction page.
& Dirty Page
Table

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• To reduce the amount of unnecessary
work, ARIES starts redoing at a point in
Topic 17
the log where it knows that previous
REDO phase changes to dirty pages have already
been applied to the database on disk.

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• Once the REDO phase is finished, the
database is in the exact state that it was in
Topic 17 when the crash occurred.
UNDO phase • The set of active transactions—called the
undo_set—has been identified in the
Transaction Table during the analysis
phase.
• Now, the UNDO phase proceeds by
scanning backward from the end of the log
and undoing the appropriate actions.

www.company.com
G. Sunil Reddy Dept of CSE
 The ARIES Recovery Algorithm
• A compensating log record is written for
each action that is undone.
Topic 17
• The UNDO reads backward in the log
UNDO phase until every action of the set of
transactions in the undo_set has been
undone.
• When this is completed, the recovery
process is finished and normal
processing can begin again.

www.company.com
G. Sunil Reddy Dept of CSE
 THANK YOU

www.company.com
G. Sunil Reddy Dept of CSE