1. Recovery

2. Recovery System
n Failure classification
n Log based recovery
n Redo recovery
n Rollback recovery
n Immediate update scheme
n Deferred update scheme
n Checkpoints
n Shadow paging
n Backups 2

3. Failure Classification
n occurs 10-100 times in a minute
n recovery required in transaction
execution time
3

4. Failure Classification
n occurs several times a week
n recovery required in a few
minutes
4

5. Failure Classification
n occurs intermittently
n recovery time depends on the nature
of failure
5

6. Failure Classification
n occurs once or twice a year
n recovery required in a few hours
6

7. ACID Properties
Atomicity is atomic; its effect on the database
is either TOTAL or NONE.
takes the database from a consistent
Consistency state to another consistent state.
The intermediate updates should not be
Isolation visible to other concurrent transactions
until it is COMMITTED.
Durability The changes to the database COMMITTED by it
should not be lost through any subsequent
failure.
7

8. How do I get the database
Transaction to its final consistent
States state?
partially committed
committed
Start
Read Ram’s account active
Debit Rs. 5000
Update Ram’s account
Read Sita’s account
failed aborted
Credit Rs. 5000
Update Sita’s account How do I get the database
End back to its consistent
state?
8

9. The Problem: Buffering!
in on
R: 15000 S: 45000 memory disk
Start
Read Ram’s account 15000 15000
Debit Rs. 5000 10000 15000
Update Ram’s account 10000 15000?
Read Sita’s account 45000 45000
Credit Rs. 5000 50000 45000
Update Sita’s account 50000 45000?
End
R: 10000 S: 50000 9

10. Log-based Recovery
n maintain a log of incremental updates
n update log before updating the database
record
n use synchronous write on log; this may be
expensive - so, most DBMS‘s use special
techniques to block log records
n log can easily get voluminous; periodic
purging or cyclic reuse resorted to
n each record minimally contains trans id, data
id, old value, new value, timestamp
10

11. Redo Recovery
old
consistent
version
roll-forward
using
after-images
new
consistent
version 11

12. Rollback Recovery
rollback
using current
before-images corrupt
verion
old
consistent
verion
12

13. The Immediate Update Scheme
n undo the last partial transaction using
the before entries
n redo all the past committed transactions
in the forward direction using the after
entries
n undo and redo are idempotent; this is
important to recover from failure during
the recovery process
13

14. The Deferred Update Scheme
n redo all the past committed transactions in
the forward direction using the after entries
n potentially heavy I/O at Commit: reads from
log file and updates on database file
n undo and redo are idempotent; this is
important to recover from failure during the
recovery process
14

15. Checkpoints
n log keeps growing with the age of the session
n recovery gets very time-consuming
n most of the efforts are really wasteful since
the updates are already on the disk, but
cannot be avoided since there is no way of
knowing where to start
15

16. Checkpoints
n Stop accepting new transactions
n Suspend execution of transactions
temporarily
n flush out all log records onto log file
n flush out buffer blocks to database
n flush out <checkpoint> log entry onto log file
n redefine the last checkpoint as the start of
the recovery process
16

17. Shadow Paging Scheme
fixed
pointer
current
page map
shadow
page map
17

18. Shadow Paging Scheme
n To commit a transaction :
1. Flush all modified pages in main memory
to disk
2. Output current page table to disk
3. Make the current page table the new
shadow page table, as follows:
n keep a pointer to the shadow page table at a fixed
(known) location on disk.
n to make the current page table the new shadow
page table, simply update the pointer to point to
current page table on disk
18

19. n Once pointer to shadow page table has
been written, transaction is committed.
n No recovery is needed after a crash —
new transactions can start right away,
using the shadow page table.
n Pages not pointed to from
current/shadow page table should be
freed (garbage collected).
19

20. On-line Backups
n set database to offline mode
n flush out all log records onto log file
n flush out <start backup> onto log file
n maintain backup log version
n flush out buffer blocks to database
n copy database to backup file
n set database to online mode and update
database using backup log
n flush out <end backup> onto log file
20

21. Off-line Backup (Dumps)
n Media Failure
n Restore from earlier backup by DBA
n Backup utilities available
n BACKUP DATABASE
n Complete vs Differential
n Replication Server
21