Database Recovery
Dr. Bassam Hammo
1
Transaction Concept
A transaction is a unit of execution
Either committed or aborted.
After a transaction, the db must be consistent.
Consistent – No violation of any constraint.
For example, if a transaction is supposed to raise the salaries of all
employees,
then the database should guarantee that when the transaction
finishes, all salaries should have been raised correctly.
2
Transaction State
3
ACID Properties
Each transaction should have:
Atomicity. Either committed or aborted.
Consistency. No violation of any constraint.
Isolation. Concurrent transactions are not aware of
each other.
Each would think it was the only running transaction
Durability. If the transaction is committed, its changes
to the db are permanent.
Even if there is a system failure.
4
Example of Fund Transfer
Transfer $50 from account A to B:
1. read(A)
2. A = A – 50
3. write(A)
4. read(B)
5. B = B + 50
6. write(B)
Consistency – Assume there is a user constraint that A + B
should remain the same. Then the database should ensure this.
Atomicity – If any step fails, then no change should be made to
the database.
5
Example of Fund Transfer (Cont.)
1. read(A)
2. A = A – 50
3. write(A)
4. read(B)
5. B = B + 50
6. write(B)
Durability – once the transaction is complete, the money
transfer is permanent.
Isolation – Assume after step 3, another transaction also needs to
access A, B. Neither transaction should affect the other.
6
Recovery Algorithms
Recovery algorithms are techniques to ensure database
consistency, transaction atomicity, and durability despite failures.
Recovery algorithms have two parts
1. Actions taken during normal transaction processing to ensure
enough information exists to recover from failures
2. Actions taken after a failure to recover the database contents
to a state that ensures atomicity, consistency and durability
7
Recovery and Atomicity
Modifying the database without ensuring that the transaction will
commit may leave the database in an inconsistent state.
Consider transaction Ti that transfers $50 from account A to
account B; our goal is either to
perform all database modifications made by Ti , or
none at all.
Operations in the transaction
Deduct from A
Add into B
Either one may fail.
8
Recovery and Atomicity (Cont.)
We will introduce two recovery methods:
log-based recovery
shadow-paging
We first assume that transactions run serially, that is, one
after the other.
And then address recovery for concurrent transactions.
9
Log-Based Recovery
A log is kept on stable storage.
Contains a sequence of log records, described as follows.
When transaction Ti starts, it registers itself by writing a
<Ti start> log record
BeforeTi executes write(X), a log record <Ti, X,V1 ,V2> is
written,
V1 is the value of X before the write
V2 is the value to be written to X.
When Ti finishes its last statement, the log record <Ti commit>
is written.
Partial commit
10
Methods of Modifying the Database
We assume all the log records are written immediately
to the disk.
But as for modifying the database contents, we have:
Deferred modification.
The database simply records all modifications to the log, but
defers all the writes to the disk after partial commit.
Immediate modification.
Change the content of the disk immediately (before partial
commit).
11
Deferred Database Modification
Transaction starts by writing <Ti start> record to log.
A write(X) operation results in a log record <Ti , X,V>, where V
is the new value for X.
Note: old value is not needed for this scheme
The write is not performed on X at this time, but is deferred.
When Ti partially commits, <Ti commit> is written to the log
Finally, the log records are read and used to actually execute the
previously deferred writes.
12
Example
T0 : T1 :
read (A) read (C)
A= A – 50 C=C- 100
write (A) write (C)
read (B)
B= B + 50
write (B)
13
Example With Crashes
T0 : T1 :
read (A) read (C)
A= A – 50 C=C- 100
write (A) write (C)
read (B)
B= B + 50
write (B)
Consider the following logs
In (a), for example, there is a crash before T0 finishes.
14
Deferred Database Modification
During the recovery from a crash, a transaction is re-executed if
both <Ti start> and<Ti commit> are present in the log.
Redoing a transaction Ti sets the value of all data items
according to the log records.
What if there is a crash during the redoing?
Say crashes in executing <T0, B, 2050> for (c)?
15
Deferred Database Modification
It doesn’t matter.
During recovery from this crash, re-do again.
Logs are idempotent.
That is, even if the operation is executed multiple times the effect
is the same as if it is executed once
16
Immediate Modification – Example
Log Update the variable
<T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050>
A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600>
C = 600
<T1 commit>
Update log record must be written before database
item is written.
17
Immediate Database Modification
Recovery procedure has two operations instead of
one:
undo(Ti)
sets the items updated by Ti to their old values,
going backwards from the last log record for Ti
redo(Ti)
sets the items updated by Ti to the new values,
going forward from the first log record for Ti
Both operations must be idempotent
18
Immediate Database Modification
When recovering after failure:
Transaction Ti needs to be undone if the log contains
<Ti start>, but not <Ti commit>.
Transaction Ti needs to be redone if the log contains
both <Ti start> and <Ti commit>.
Undo operations are performed first, then redo operations.
19
Example with Crashes
(a) undo (T0): B is restored to 2000 and A to 1000.
(b) undo (T1) and redo (T0): C is restored to 700, and then A and B
are
set to 950 and 2050 respectively.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050
respectively. Then C is set to 600
20
Checkpoints
In the previous slides, when there are multiple
transactions to be executed, we first obtain the logs
of all of them, before physically executing the log
records.
Problems:
A very long log list.
Searching inside the log is time-consuming (e.g., for
start/commit records)
We might unnecessarily redo transactions
multiple times.
If a crash happens during redoing.
Solution: checkpoints
21
Example
<T1 start>
<T1, A, 0, 10>
<T1 commit>
<T2 start>
<T2, B, 0, 10>
<checkpoint > physically execute the above records
<T2, C, 0, 10>
<T2 commit>
<T3 start>
<T3, A, 10, 20>
<T3, D, 0, 10>
<T3 commit>
<T4 start>
<T4, A, 20, 30>
failure
22
Example of Checkpoints
Tc Tf
T1
T2
T3
T4
checkpoint system failure
T1 can be ignored (updates already output to disk due to
checkpoint)
T2 and T3 redone.
But for T2, redo only the part after the checkpoint.
T4 undone
23
Checkpoints
At each checkpoint, physically execute the log
records before it.
During recovery we need to consider only
the most recent transaction that started before the
checkpoint
E.g., T2 on the previous slide
all transactions that started after.
E.g., T3, T4
24
Data Access
Physical blocks are those blocks residing on the
disk.
Buffer blocks are the blocks residing temporarily in
main memory.
Each transaction Ti has its “private work-area”
in which local copies of all data items accessed and
updated by it are kept.
Ti 's local copy of a data item X is called xi.
25
Data Access (Cont.)
buffer
Buffer Block A x input(A)
Buffer Block B Y A
output(B) B
read(X)
write(Y)
x2 disk
x1
y1
work area work area
of T1 of T2
memory
26
Data Access (Cont.)
Two levels of data access
buffer blocks disk blocks
transaction work area buffer blocks
buffer blocks disk blocks
input(B) transfers the physical block B to main
memory.
output(B) transfers the buffer block B to the disk,
and replaces the appropriate physical block there.
27
Data Access (Cont.)
transaction work area buffer blocks
read(X): brings the value of buffered item X to the
local variable xi.
write(X): assigns the value of local variable xi to
buffered item X.
28
