Transaction Processing concepts,

Concurrency Control and Recovery

PART 3

1
 Objectives of the Lecture
• Discuss database recovery issues:
– Recovery from catastrophic (like disc crash) failure, and
– recovery from a non-catastrophic failure
 Requirements for Database Consistency -
recall
• Concurrency Control
– The concurrent execution of many different transactions submitted by
various users must be organized such that each transaction does not
interfere with another transaction in a way that produces incorrect
results. i.e. the concurrent execution of transactions must be such that
each transaction appears to execute in isolation.

• Recovery
– System failures, either hardware or software, must not result in an
inconsistent database
 Transaction as a Recovery Unit
• If any of the below occurs between the begin and end of a
transaction, the database will be inconsistent!
– Computer Failure (system crash)
– A transaction or system error
– Local errors or exception conditions detected by the
transaction
– Concurrency control enforcement
– Disk failure
– Physical problems and catastrophes
• The database is restored to some state from the past so that a
correct state—close to the time of failure—can be reconstructed
from the past state.
• The statements COMMIT and ROLLBACK (or their equivalent)
ensure Transaction Atomicity
 Transaction as a Recovery Unit(2)
• A DBMS ensures that if a transaction executes
some updates and then a failure occurs before
the transaction reaches normal termination,
then those updates are undone.
• A DBMS also ensures that if a transaction
executes some updates and commits, then a
failure occurs thereafter, then those updates
are redone.
 Why “Database Recovery Techniques”?
System crash
Transaction error
System error
T1 Crash Local error
T2 Disk failure
T3 Catastrophe
Time

• ACID properties of Transaction

Database system should guarantee
- Durability : Applied changes by transactions

must not be lost. ~ T1, T2

- Atomicity : Transactions can be aborted.
~ T3
 Classification of failures
• According to type of the failure recovery procedures
classify to:
– Recovery from catastrophic (like disc crash) failure, and
– recovery from a non-catastrophic failure
Catastrophic failure:
• Restore from a previous copy of the database from archival
backup.
• Apply transaction log to backup copy to reconstruct more
current state by redoing committed transaction operations
up to failure point
Recovery from Catastrophic failure:
Recovery from Catastrophic failure
• Full DB Backup
• > Differential Backup • Catastrophic failure
• > (Transaction) Log

• You should read on different strategies/types

of backup
• Full
• Incremental
• differential
 Non-catastrophic failures
• A computer failure
– Hardware failure
– Software failure
– Network failure
• A transaction error
– Integer overflow
– Division by zero
– Logical error
– Exception condition
– User interruption
• Concurrency control enforcement
– Violated serializability
– deadlock
 Non-catastrophic failure recovery
• Assumes that data on disk is safe (thus only considers
recovery from non-disk failures)
• Generally, if a DB becomes inconsistent due to a non-
catastrophic failure, the idea is to reverse those
changes that make it inconsistent.
• Recovery can be based on many algorithms including:
– Deferred update
– Immediate update and
– Shadow paging
 Basic Concepts : “Logging”
Backup Checkpoint
System Log
- keeps info of changes
applied by transactions

T1
T2 Crash
T3
Time

• Undo/Redo done using the Log

 recover Non-catastrophic failure
 Transaction and System Concepts

• The System Log

– Log or Journal: The log keeps track of all transaction
operations that affect the values of database items.
• This information may be needed to permit recovery from
transaction failures.
• 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.
 Transaction and System Concepts (2)

• The System Log (cont):

– T in the following discussion refers to a unique transaction-id that is
generated automatically by the system and is used to identify each
transaction:
– Types of log record:
• [start_transaction,T]: Records that transaction T has started
execution.
• [write_item,T,X,old_value,new_value]: Records that transaction
T has changed the value of database item X from old_value to
new_value.
• [read_item,T,X]: Records that transaction T has read the value of
database item X.
• [commit,T]: Records that transaction T has completed
successfully, and affirms that its effect can be committed
(recorded permanently) to the database.
• [abort,T]: Records that transaction T has been aborted.
 Transaction and System Concepts (3)

• The System Log (cont):

– Protocols for recovery that avoid cascading
rollbacks do not require that read operations be
written to the system log, whereas other protocols
require these entries for recovery.
– Strict protocols require simpler write entries that
do not include new_value.
 Transaction and System Concepts (4)

Recovery using log records:

• If the system crashes, we can recover to a
consistent database state by examining the log
1. Because the log contains a record of every write operation that
changes the value of some database item, it is possible to undo the
effect of these write operations of a transaction T by tracing
backward through the log and resetting all items changed by a
write operation of T to their old_values.

2. We can also redo the effect of the write operations of a transaction

T by tracing forward through the log and setting all items changed
by a write operation of T (that did not get done permanently) to
their new_values.
 Entries in the System
For every transaction a unique transaction-id is generated by the
Log
Credit_labmark (sno
system. NUMBER, cno CHAR, credit
NUMBER)
• [start_transaction, transaction-id]: the start of execution of old_mark NUMBER;
the transaction identified by transaction-id new_mark NUMBER;

SELECT labmark INTO

• [read_item, transaction-id, X]: the transaction identified by old_mark FROM enrol
transaction-id reads the value of database item X. Optional in WHERE studno = sno and
some protocols. courseno = cno FOR UPDATE
OF labmark;
• [write_item, transaction-id, X, old_value, new_value]: the
transaction identified by transaction-id changes the value of new_ mark := old_ mark +
database item X from old_value to new_value credit;

UPDATE enrol SET labmark

= new_mark WHERE studno =
• [commit, transaction-id]: the transaction identified by sno and courseno = cno ;

transaction-id has completed all accesses to the database COMMIT;

successfully and its effect can be recorded permanently
(committed) EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
• [abort, transaction-id]: the transaction identified by
transaction-id has been aborted END credit_labmark;
 Transaction execution
A transaction reaches its commit point when all
operations accessing the database are completed
and the result has been recorded in the log. It then
writes a [commit, transaction-id].
BEGIN END
TRANSACTION TRANSACTION
active partially
committed COMMIT
committed

ROLLBACK ROLLBACK
READ, WRITE

terminated
failed

If a system failure occurs, searching the log and rollback the transactions that
have written into the log a
[start_transaction, transaction-id]
[write_item, transaction-id, X, old_value, new_value]
but have not recorded into the log a [commit, transaction-id]
 Physical View - How they work - (1)
Memory
Disk
A DBMS cache
copy
(buffers)
B a
flush Directory
(address:A,a,1)
B’
Disk pages/blocks b (address:B,b,0)

Action :
1) Check the directory whether in the cache
2) If none, copy from disk pages to the cache
3) For the copy, old buffers needs to be flushed
from the cache to the disk pages
 Physical View - How they work - (2)
Memory
Disk
A DBMS cache
copy
(buffers)
B a update
flush Directory
(address:A,a,1)
B’
Disk pages/blocks b (address:B,b,0)

4) Flush only if a dirty bit is 1

Dirty bit : (in the directory) indicates whether there is
a change after copy to the cache
1 – updated in the cache
0 – not updated in the cache (no need to flush)
 Physical View - How they work - (3)
Memory
Disk
A DBMS cache
copy
(buffers)
B a
flush

B’
Disk pages/blocks b

A-a : “in-place updating”

- when flushing, overwrite at the same location
- logging is required

B-b : “shadowing”
 Physical View - How they work - (4)
Memory
Disk
DBMS cache
B
copy b update
update
B’ Data Log
Data blocks flush
blocks blocks

Log blocks

(1) copy (from the disk to the cache)

(2) update the cached data, record it in the log
(3) flush the log and the data
(from the cache to the disk)
 Basic Concepts: Steal & No-Force (1)
 Typical DB employs a steal/no-force strategy
 Steal strategy : a transaction can be written to disk
commit before it commits
T1 commit
T2
T3
Time

cache cache
Can be Used for other
transactions (T3)
Updated
data by T2
Advantage :
buffer space saving
before T2 commits
 Basic Concepts: Steal & No-Force (2)
 No-Force strategy : a transaction need not be
written to disk immediately
when it commits
T1
commit Advantage :
commit
T2 I/O operations saving
T3
Time

cache cache
If T3 needs the same data, it
Updated must be copied again
data by T2

 Force strategy
when T2 commits
 Basic Concepts: Checkpointing
 At a Checkpoint
- temporarily suspend all transactions
- Force write results of all update operations of committed
transactions from memory to disk
- A record is written into the log file and log force written to disk.
([checkpoint])
- Resume executing transactions
• Periodically done (e.g. every n min. or every n transaction)

Checkpoint

T1 Crash
T2
T3
Time
 Transaction Rollback (1)
 Rollback / Roll foward
Recovery method
1 : Not necesary
T1
Crash 2 : Roll foward
T2
T3 3 : Rollback
T4 4 : Roll forward
T5 5 : ignore
Time
Checkpoint

- Steal : transaction may be written on disk

before it commits
 Transaction Rollback (2)
 example :
read(A) write(A) read(B) write(B)
T1
read(A) write(A) read(C) write(C)
T2
Time
Checkpoint Crash

T1 : A company pays salary to employees

Name Account i) transfer $2,000 to Mr. A’s account
ii) transfer $2,500 to Mr B’s account …
Mr.A $10
T2 : Mr.A pays the monthly rent.
Mr.B $2,000 i) withdraw $1,500 from Mr.A’s account
Mr.C $30,000 ii) transfer $1,500 to Mr.C’s account
 Transaction Rollback (3)
 Cascading Rollback r(A) w(A) r (B)
T1
- T1 is interrupted r(A) w(A) w(C) r(C)
(needs rollback) T2

Checkpoint Crash
System Log A C
[checkpoint] $10 $30,000
[start_transaction, T1]
[read_item, T1, A] $10
[write_item, T1, A, 10, 2010] $2,010
[start_transaction, T2] - T2 uses value
[read_item, T2, A] $2,010
[write_item, T2, A, 2010, 510]
modified by T1
$510
[read_item, T1, B] (also needs
[read_item, T2, C] $30,000 rollback)
[write_item, T2, C, 1500, 31500] $31,500
~~~ CRASH ~~~~
 Categorization of Recovery Algorithm
• Deferred update – the No-UNDO/REDO algorithm
 Immediate update –
 the UNDO/REDO algorithm
 UNDO/No-REDO
 Deferred Update
Deferred Update:
– Idea is that no actual update of the database until after a transaction reaches
its commit point
1. During execution updates are recorded in log
2. Just before transaction commit point, all log updates are written to the log
file in disk, and then the transaction commits.
3. After that, update the database

FAILURE!
• REDO committed transaction to database from log entries
• No UNDO necessary because database never altered
 Immediate Update
Immediate Update general concept:
– the database may be updated by some operations
of a transaction before it reaches its commit point.
• Thus an update X recorded in log is also leads to an
update X in database
• There are two versions:
– one, where all updates are written to disk before
transaction commits
– Two, where transaction commits before all its
updates are written to disk
 Recovery Timeline
Checkpoint Failure

Time

T1

T2

T3

T4

T5
 Recovery Processes summary
• Depend on timing of database writes (force or
no-force)
• Immediate update approach:
– Before commit
– Log records written first (write-ahead log protocol)
• Deferred update approach
– After commit
– Undo operations not needed
 Other methods for recovery
• Shadow paging – read on your own