Topics From

CH20: Introduction to Transaction Processing Concepts and Theory

CH21: Concurrency Control Techniques
CH22: Database Recovery Techniques

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Single-User versus Multiuser Systems
 A DBMS is single-user if at most one user at a
time can use the system and mostly restricted to
personal computer systems.
 A DBMS is multiuser if many users can use the
system and hence access the database
concurrently.
 Multiple users can access simultaneously because
of the concept of multiprogramming, which allows
the operating system of the computer to execute
multiple programs at the same time.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 2

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 3
 Transaction
 A transaction is an executing program that
forms a logical unit of database processing
and includes one or more database access
operations (insertion, deletion, update, or
retrieval).
 If the database operations in a transaction do
not update the database but only retrieve
data, the transaction is called a read-only
transaction; otherwise it is known as a read-
write transaction.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 4
 Example of a simple
transaction. Suppose
a bank employee
transfers Rs 500 from
A's account to B's
account

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 5

 Transaction
 Transaction Processing Systems are systems
with large databases and hundreds of concurrent
users executing database transactions.
 Examples of such systems include airline
reservations, banking, credit card processing,
online retail purchasing, stock markets,
supermarket checkouts, and many other
applications.
 These systems require high availability and fast
response time for hundreds of concurrent users.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 6
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 7
Concurrency control and recovery
mechanisms
 Concurrency control and recovery mechanisms are
mainly concerned with the database commands in a
transaction.
 One way of specifying the transaction boundaries is by
specifying explicit begin transaction and end
transaction statements in an application program; all
database access operations between the two are
forming one transaction.
 Transactions submitted by the various users may
execute concurrently and may access and update the
same database items. If this concurrent execution is
uncontrolled, it may lead to problems.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 8
Problems in Execute of Uncontrolled
Concurrent Transactions
Several problems can occur when concurrent
transactions execute in an uncontrolled manner such
as:
 The Lost Update Problem. This problem occurs

when two transactions that access the same

database items have their operations interleaved in
a way that makes the value of some database
items incorrect.
 The Temporary Update (or Dirty Read) Problem:

This problem occurs when one transaction updates

a database item and then the transaction fails for
some reason.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 9
Example for Lost Update Problems: Consider the below diagram
where two transactions TX and TY, are performed on the same
account A where the balance of account A is $300

 At time t7,
transaction
TY writes the values
of account A, so it
will write as done at
time t4 that will be
$400.
 It means the value
written by TX is lost,
i.e., $250 is lost

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 10

Example for temporary Update (or Dirty Read) Problem:
Consider two transactions TX and TY in the below diagram
performing read/write operations on account A where the
available balance in account A is $300:
 At time t4, transaction
TY reads account A that will
be read as $350.
 At time t5, transaction
TX rollbacks due to server
problem, and the value
changes back to $300 (as
initially).
 But the value for account A
remains $350 for transaction
TY as committed, which is
the dirty read and therefore
known as the Dirty Read
Problem
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 11
 Problems in Execute of Uncontrolled
Concurrent Transactions
 The Incorrect Summary Problem. If one
transaction is calculating an aggregate summary
function on a number of database items while other
transactions are updating some of these items, the
aggregate function may calculate some values
before they are updated and others after they are
updated.
 The Unrepeatable Read Problem: where a
transaction T reads the same item twice and the item
is changed by another transaction T′ between the
two reads. Hence, T receives different values for its
two reads of the same item. Slide 21- 12
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Example for The Incorrect Summary Problem:
A=100, X=100, Y=100, N=50
 Transaction 2 is calculating the
sum of some records while
transaction 1 is updating them.
 Aggregate function calculate
some values before they have
Sum=100 been updated (Y) and others after
X=50 they have been updated (X).
 Sum at T2 =250 but if T execute
Sum=150 first Sum will be 300.
 It is an Incorrect Summary
Sum=250
Problem

Y=150
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 13
Example for Unrepeatable Read Problem: Consider two
transactions, TX and TY, performing the read/write operations
on account A, having an available balance = $300

 At time t1, transaction TX reads

the value from account A, $300
 At time t4, transaction TY writes
the updated value, $400.
 at time t5, transaction TX reads
the available value of account A,
and that will be read as $400.
 within the same transaction TX,
it reads two different values of
account A, 300 and $400. It is
an unrepeatable read and is
therefore known as the
Unrepeatable read problem.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 14
 Types of transaction Failures
 There are several possible reasons for a transaction
to fail in the middle of execution:
 A computer failure (system crash): A hardware,
software, or network error occurs in the computer
system during transaction execution.
 A transaction or system error: Some operation in
the transaction may cause it to fail, such as integer
overflow or division by zero.
 Local errors or exception conditions detected by
the transaction. During transaction execution,
certain conditions may occur that necessitate
cancellation of the transaction.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 15
 Types of transaction Failures
 Concurrency control enforcement: The concurrency
control method may abort a transaction because it
violates serializability or it may abort one or more
transactions to resolve a state of deadlock among
several transactions.
 Disk failure: Some disk blocks may lose their data
because of a read or write malfunction or because of a
disk read/write head crash.
 Physical problems and catastrophes: This refers to
an endless list of problems that includes power or air-
conditioning failure, fire, theft, sabotage, and
overwriting disks or tapes by mistake.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 16

Transaction States and Additional
Operations
 For recovery purposes, the system needs to keep
track of when each transaction starts, terminates,
and commits, or aborts.
 The recovery manager of the DBMS needs to keep
track of the following operations:
 BEGIN_TRANSACTION
 READ or WRITE
 END_TRANSACTION
 COMMIT_TRANSACTION
 ROLLBACK (or ABORT)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 17

 State transition diagram illustrating the states
for transaction execution.

• Active: the transaction is being executed. This is the initial state

of every transaction.
• Partially Committed: transaction executes its final operation.
• Failed : if any of the checks made by the database recovery
system fails.
• Aborted: If any of the checks fails and the transaction has
reached a failed state, then the recovery manager rolls back all
its write operations on the database to bring the database back
to its original.
• Committed: If andaShamkant
Copyright © 2016 Ramez Elmasri transaction
B. Navathe executes all its operations
Slide 21- 18
Locking Techniques for Concurrency
Control
 Some of the main techniques used to control
concurrent execution of transactions are based
on the concept of locking data items.
 A lock is a variable associated with a data item
that describes the status of the item. Types of
luck are:
 Binary lock: can have two states or values
locked and unlocked
 Shared/exclusive or read/write locks: there are
three locking operations: read_lock(X),
write_lock(X), and unlock(X).
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 19
Locking Techniques for Concurrency
Control
Pre-claiming
Lock
Protocol:

Two-Phase
Locking 2PL

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 20

Timestamp-based Techniques for
Concurrency Control
 Timestamp based techniques is commonly used
in concurrency control and uses either system
time or logical counter as a timestamp
 Lock-based techniques manage the order
between the conflicting pairs among transactions
at the time of execution.
 Every transaction has a timestamp associated
with it, and the ordering is determined by the age
of the transaction.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 21

Lock Problems: deadlock
 Deadlock occurs when each transaction T in a set
of two or more transactions is waiting for some item
that is locked by some other transaction T′ in the
set. Hence,
 Each transaction in the set is in a waiting queue,
waiting for one of the other transactions in the set to
release the lock on an item.
 But because the other transaction is also waiting, it
will never release the lock.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 22

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 23
Lock Problems: deadlock
Deadlock Handling Methods are:
 Deadlock Ignorance: Whenever a deadlock situation occurs,

simply ignore the deadlock.

 Deadlock Prevention: try to prevent the deadlock from

happening.
 Deadlock Avoidance: try to avoid deadlocks by use of prior

knowledge about the usage of the resources available,

resources allocated, future resources requests, and future
releases by the processes.
 Deadlock Detection: If deadlock prevention and avoidance

are not done properly then the system may detect the
deadlock and recover it.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 24

Lock Problems: starvation
 Starvation: occurs when a transaction cannot
proceed for an indefinite period of time while
other transactions in the system continue
normally.
 This may occur if the waiting scheme for locked
items is unfair in that it gives priority to some
transactions over others.
 One solution for starvation is to have a fair
waiting scheme, such as using a first-come-first-
served queue or allows some transactions to
have priority over others.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 25
 Recovery
 Recovery from transaction failures usually means that the
database is restored to the most recent consistent state before
the time of failure.
 The system keep information about the changes that were
applied to data items by the various transactions in the
system log.
 When the system is crashed, then the system consults the log:

 If the log contains the record <Ti, Start> and <Ti, Commit> then
the Transaction Ti needs to be redo.
 If log contains record<Tn, Start> but does not contain the record
either <Ti, commit> or <Ti, abort>, then the Transaction Ti needs
to be undo.
 Undo helps in rollback while redo helps in rolling forward.
Slide 22- 26
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
 A Typical Strategy For Recovery
 If there is extensive damage to a wide portion of the database
due to catastrophic failure, such as a disk crash, the recovery
method:
 Restores a past copy of the database that was backed up

to archival storage.
 Reconstructs a more current state by redoing the

operations of committed transactions from the backed-up

log, up to the time of failure.
 Else, when the database on disk is not physically damaged,
the recovery strategy is to identify any changes that may
cause an inconsistency in the database.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 27

 Checkpoints
 The checkpoint is a type of mechanism where all the
previous logs are removed from the system and
permanently stored in the storage disk.
 When it reaches to the checkpoint, then the
transaction will be updated into the database, and till
that point, the entire log file will be removed from the
file. Then the log file is updated with the new step of
transaction till next checkpoint and so on.
 The checkpoint is used to declare a point before
which the DBMS was in the consistent state, and all
transactions were committed.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 28

 Recovery using Checkpoint

 Puts T1, T2 and T3 transaction into redo list

 Puts T4 into undo list

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 29

Policies for recovery from non-catastrophic
transaction failures
 Deferred update techniques:
 do not physically update the database on disk until

after a transaction commits; then the updates are

recorded in the database.
 is also known as the NO-UNDO/REDO algorithm.

 Immediate update techniques

 the database may be updated by some operations

of a transaction before the transaction reaches its

commit point.
 known as the UNDO/REDO algorithm.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 30

 NO-UNDO/REDO Recovery Based
on Deferred Update
 The idea behind deferred update is to defer or postpone any actual
updates to the database on disk until the transaction completes its
execution successfully and reaches its commit point.
 During transaction execution, the updates are recorded only in the log
and in the cache buffers. After the transaction reaches its commit point
and the log is force written to disk, the updates are recorded in the
database.
 If a transaction fails before reaching its commit point, there is no need
to undo any operations because the transaction has not affected the
database on disk in any way.
 Therefore, only REDO type log entries are needed in the log, which
include the new value of the item written by a write operation. The
UNDO-type log entries are not needed since no undoing of
operations will be required during recovery.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 31

NO-UNDO/REDO Recovery Based
on Deferred Update

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 32

Deferred update in a multi-user environment
To save redo effort, use checkpoints

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 33

 Recovery Techniques Based
on Immediate Update
 Updates of a transaction may be written to disk before the
transaction commits (with the log records for such updates
being written out first, i.e., write-ahead logging)
 Additional requirement: all updates of a transaction T must be
written to disk before the commit point of T
 No need to redo changes of committed transactions

 Need to undo changes of non-committed transactions

 UNDO/NO-REDO recovery algorithm:

 Create a list of active (i.e., non-committed) transactions

 UNDO all the write-item operations of all the TAs in the list in

the reverse order in which they appear in the log (use before
image from the log records).
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 34
 UNDO/NO-REDO recovery algorithm

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 35

Recovery Techniques Based
on Immediate Update
 UNDO/REDO recovery algorithm:
 Create a list of active (i.e., non-committed)
transactions, and a list of committed transactions
since last checkpoint
 UNDO all the write-item operations of all the TAs in
the first list in the reverse order in which they
appear in the log (use before image from the log
records)
 REDO all the write-item operations of all the TAs in
the second list in the order in which they appear in
the log (use after image from the log records)
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 36
UNDO/REDO recovery algorithm

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 37

 The System Log
 To be able to recover from failures that affect
transactions, the system maintains a log to keep
track of all transaction operations that affect the
values of database items and other transaction
information that may be needed to permit recovery
from failures.
 The log is a sequential, append-only file that is kept
on disk, so it is not affected by any type of failure
except for disk or catastrophic failure.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 38

Database Buffer Cache
 The database buffer cache, also called the buffer
cache, is the memory area that stores copies of
data blocks read from data files.
 A buffer is a main memory address in which the
buffer manager temporarily caches a currently or
recently used data block.
 All users concurrently connected to a database
instance share access to the buffer cache.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 39

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 40
 Strategies Can Be Employed When
Flushing A Modified Buffer Back To Disk
 Two main strategies can be employed when flushing a
modified buffer back to disk.
 In-place updating: writes the buffer to the same original

disk location, thus overwriting the old value of any changed

data items on disk.
 Shadowing: writes an updated buffer at a different disk

location, so multiple versions of data items can be

maintained. But, not typically used in practice.
 The old value of the data item before updating is called the
before image (BFIM),
 The new value after updating is called the after image (AFIM)
 If shadowing is used, both the BFIM and the AFIM can be kept
on disk.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 41
 Write-Ahead Logging
 Write-ahead logging: the recovery mechanism ensure that
the BFIM of the data item is recorded in the appropriate log
entry and that the log entry is flushed to disk before the BFIM
is overwritten with the AFIM in the database on disk.
 REDO-type log entry: includes the new value (AFIM) of the
item written by the operation since this is needed to redo the
effect of the operation from the log.
 UNDO-type log entries include the old value (BFIM) of the
item since this is needed to undo the effect of the operation
from the log (by setting the item value in the database back
to its BFIM).
 In an UNDO/REDO algorithm, both BFIM and AFIM are
recorded into a single log entry.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 42
 Steal/no-steal
 Steal/no-steal and force/no-force
 Specify rules that govern when a page from the
database cache can be written to disk
 No-steal approach
 Cache buffer page updated by a transaction
cannot be written to disk before the transaction
commits
 Steal approach
 Recovery protocol allows writing an updated buffer
before the transaction commits

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 43

 Force/No-force approach
 Force approach
 All pages updated by a transaction are
immediately written to disk before the transaction
commits
 Otherwise, no-force
 Typical database systems employ a steal/no-
force strategy
 Avoids need for very large buffer space
 Reduces disk I/O operations for heavily updated
pages

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 44

 Transaction Rollback
 Transaction failure after update but before
commit
 Necessary to roll back the transaction
 Old data values restored using undo-type log
entries
 Cascading rollback
 If transaction T is rolled back, any transaction S
that has read value of item written by T must also
be rolled back
 Almost all recovery mechanisms designed to avoid
this
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 45
Cascading
rollback

Transaction T10 writes a value of A that is read by

Transaction T11. Transaction T11 writes a value of A
that is read by Transaction T12.
Suppose at this point T10 fails. T10 must be rolled
back, since T11 is dependent on T10, T11 must be
rolled back, T12 is dependent on T11, T12 must be
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 46
Transactions that Do Not Affect the
Database
 Example actions: generating and printing
messages and reports
 If transaction fails before completion, may not
want user to get these reports
 Reports should be generated only after transaction
reaches commit point
 Commands that generate reports issued as batch
jobs executed only after transaction reaches
commit point
 Batch jobs canceled if transaction fails

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 47

Shadow Paging
 No log required in a single-user environment
 Log may be needed in a multiuser environment for
the concurrency control method
 Shadow paging considers disk to be made of n
fixed-size disk pages
 Directory with n entries is constructed
 When transaction begins executing, directory
copied into shadow directory to save while current
directory is being used
 Shadow directory is never modified

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 48

Database Backup
 The recovery manager of a DBMS must also be
equipped to handle more catastrophic failures such as
disk crashes.
 Database backup is a technique used to handle disk
crashes, in which the whole database and the log are
periodically copied onto a cheap storage medium such
as magnetic tapes or other large capacity offline
storage devices..
 Latest backup copy can be reloaded from disk in case
of catastrophic failure
 Backups often moved to physically separate location.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 49
 Methods of Database Backup
 The different methods of backup in a database are:
 Full Backup: This method takes a lot of time as the full

copy of the database is made including the data and the

transaction records.
 Transaction Log: Only the transaction logs are saved

as the backup in this method. To keep the backup file as

small as possible, the previous transaction log details
are deleted once a new backup record is made.
 Differential Backup: This is similar to full backup in that

it stores both the data and the transaction records.

However only that information is saved in the backup
that has changed since the last full backup. Because of
this, differential backup leads to smaller files.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 50