Database Recovery Techniques

Lecture Outline
Databases Recovery 1 Purpose of Database Recovery 2 Types of Failure 3 Transaction Log 4 Data Updates 5 Data Caching 6 Transaction Roll-back (Undo) and Roll-Forward 7 Checkpointing 8 Recovery schemes

Yugma Kumar Agrawal

Chapter 19 (E & M)-2

Database Recovery
Purpose of Database Recovery To bring the database into the last consistent state, which existed prior to the failure. To preserve transaction properties (Atomicity, Consistency, Isolation and Durability). Example: If the system crashes before a fund transfer transaction completes its execution, then either one or both accounts may have incorrect value. Thus, the database must be restored to the state before the transaction modified any of the accounts.

Yugma Kumar Agrawal

Chapter 19 (E & M)-3

Database Recovery
Types of Failure The database may become unavailable for use due to Transaction failure: Transactions may fail because of incorrect input, deadlock, incorrect synchronization. System failure: System may fail because of addressing error, application error, operating system fault, RAM failure, etc. Media failure: Disk head crash, power disruption, etc.

Yugma Kumar Agrawal

Chapter 19 (E & M)-4

Database Recovery
System Log For the recovery purpose system must keep information about the changes that were applied to data items by the various transactions. This information is kept in the system Log

Yugma Kumar Agrawal

Chapter 19 (E & M)-5

Database Recovery
The are two techniques for recovery from non catastrophic transaction failure.
Deferred Update: All modified data items in the cache is written either after a transaction ends its execution or after a fixed number of transactions have completed their execution. Immediate Update: As soon as a data item is modified in cache, the disk copy is updated.

Yugma Kumar Agrawal

Chapter 19 (E & M)-6

Deferred Update
The database is not physically update on the disk until after a transaction reaches its commit point. Before commit point all transaction updates are recorded in the local transaction workspace. During commit, the updates are first recorded in the log and then written to the database. If a transaction fails before reaching its commit point, it will not have changed the database in any way, so no UNDO in needed. It may be necessary to REDO the effects of operations of committed transactions from the log because their effect may not be recorded in the database. Deferred update is also known as NO-UNDO/REDO algorithm
Chapter 19 (E & M)-7

Yugma Kumar Agrawal

Immediate Update
The database is updated by some operations of a transaction before the transaction reaches its commit point. The operations are recorded in the log on disk by force writing before they are applied to the database. If transaction fails after recording some changes in the database but before reaching its commit point, the effects of its operations must be undone. Both UNDO and REDO operations are required. This technique is known as UNDO/REDO algorithm.

Yugma Kumar Agrawal

Chapter 19 (E & M)-8

Data Caching
Data items to be modified are first stored into database cache by the Cache Manager (CM) and after modification they are flushed (written) to the disk. The flushing is controlled by dirty and Pin-Unpin bits.
Dirty Bit: Indicates whether the buffer is modified or not. Pin-Unpin: Instructs the operating system not to flush the data item.

Two main strategies of flushing a modified buffer back to disk.

In-place updating Shadowing
Yugma Kumar Agrawal

Chapter 19 (E & M)-9

In-Place Updating
Writes the buffer back to the same original disk location, thus overwriting the old value of any changed items on the disk. A single copy of each database disk block is maintained.

Yugma Kumar Agrawal

Chapter 19 (E & M)-10

Shadowing
Write an updated buffer at a different disk location. Multiple versions of data items exists. The old value of the data item before updating is called before image (BFIM) and the new value after updating is called the after image (AFIM). Both BFIM and AFIM can be kept on the disk.

Yugma Kumar Agrawal

Chapter 19 (E & M)-11

Transaction Roll-back (Undo) and Roll-Forward (Redo)

To maintain atomicity, a transactions operations are redone or undone. Undo: Restore all BFIMs on to disk (Remove all AFIMs). Redo: Restore all AFIMs on to disk. Database recovery is achieved either by performing only Undos or only Redos or by a combination of the two. These operations are recorded in the log as they happen.

Yugma Kumar Agrawal

Chapter 19 (E & M)-12

Roll Back (1)

We show the process of roll-back with the help of the following three transactions T1, and T2 and T3.

T1 read_item (A) read_item (D) write_item (D)

T2 read_item (B) write_item (B) read_item (D) write_item (A)

T3 read_item (C) write_item (B) read_item (A) write_item (A)

Yugma Kumar Agrawal

Chapter 19 (E & M)-13

Roll Back (2)

Roll-back: One execution of T1, T2 and T3 as recorded in the log.
A 30
[start_transaction, T3] [read_item, T3, C] * [write_item, T3, B, 15, 12] [start_transaction,T2] [read_item, T2, B] ** [write_item, T2, B, 12, 18] [start_transaction,T1] [read_item, T1, A] [read_item, T1, D] [write_item, T1, D, 20, 25] [read_item, T2, D] ** [write_item, T2, D, 25, 26] [read_item, T3, A]

B 15

C 40

D 20

12

18

25 26

---- system crash ---* T3 is rolled back because it did not reach its commit point. ** T2 is rolled back because it reads the value of item B written by T3.
Yugma Kumar Agrawal

Chapter 19 (E & M)-14

Roll Back (3)

Roll-back: One execution of T1, T2 and T3 as recorded in the log.
T3 READ(C) WRITE(B) BEGIN T2 BEGIN READ(B) WRITE(B) T1 BEGIN READ(A) READ(D) WRITE(D)

READ(A) READ(D) WRITE(D)

Time system crash

Illustrating cascading roll-back

Yugma Kumar Agrawal

Chapter 19 (E & M)-15

Write-Ahead Logging
When in-place update (immediate or deferred) is used then log is necessary for recovery and it must be available to recovery manager. This is achieved by Write-Ahead Logging (WAL) protocol. WAL states that
For Undo: Before a data items AFIM is flushed to the database disk (overwriting the BFIM) its BFIM must be written to the log and the log must be saved on a stable store (log disk). For Redo: Before a transaction executes its commit operation, all its AFIMs must be written to the log and the log must be saved on a stable store.

Yugma Kumar Agrawal

Chapter 19 (E & M)-16

Steal/No-Steal and Force/No-Force

Possible ways for flushing database cache to database disk: Steal: Cache can be flushed before transaction commits. No-Steal: Cache cannot be flushed before transaction commit. Force: Cache is immediately written to disk when the transaction commits. No-Force: Cache is flushed to disk later.

Yugma Kumar Agrawal

Chapter 19 (E & M)-17

Checkpoints
A checkpoint is written in the log when the database write all the modified buffers to the disk. All the transactions that have their commit entries in the log before checkpoint entry do not need to be redone in case of system crash. The recovery manager must decide at what intervals to take a checkpoint. Taking a checkpoint consist of following actions.
Suspend execution of transactions temporarily. Force write modified buffer data to disk. Write a [checkpoint] record to the log, save the log to disk. Resume normal transaction execution.
Chapter 19 (E & M)-18

Yugma Kumar Agrawal

Database Recovery Based on Deferred Update

A transaction cannot change the database on the disk until it reaches its commit point. A transaction does not reach its commit point until all its update operations are recorded in the log and the log is force-written to disk. Since the database is never updates on the disk until after transaction commits, there is never a need to undo any operations. Redo is needed in the case system fails after a transaction commits but before all its changes are recorded in the database on disk.
Chapter 19 (E & M)-19

Yugma Kumar Agrawal

Deferred Update in single user system (1) Use two lists of transactions: the committed transactions since the last checkpoint, and the active transactions. Apply the REDO operations to all the WRITE_ITEM operations of the committed transactions from log in the order in which they were written to the log. Restart the active transactions

Yugma Kumar Agrawal

Chapter 19 (E & M)-20

Deferred Update in single user system (2)

(a) T1 read_item (A) read_item (D) write_item (D) T2 read_item (B) write_item (B) read_item (D) write_item (A)

(b) [start_transaction, T1] [write_item, T1, D, 20] [commit T1] [start_transaction, T2] [write_item, T2, B, 10] [write_item, T2, D, 25] system crash The [write_item, ] operations of T1 are redone. T2 log entries are ignored by the recovery manager.
Yugma Kumar Agrawal

Chapter 19 (E & M)-21

Deferred Update in concurrent user system (1) This environment requires some concurrency control mechanism to guarantee isolation property of transactions. Procedure Use two lists of transactions: the committed transactions since the last checkpoint, and the active transactions. Apply the REDO operations to all the WRITE_ITEM operations of the committed transactions from log in the order in which they were written to the log. Restart the active transactions
Yugma Kumar Agrawal

Chapter 19 (E & M)-22

Deferred Update in concurrent user system (2)

T1 T2 T3 T4 T5 t1 Time checkpoint t2

system crash

Recovery in a concurrent users environment.

Yugma Kumar Agrawal

Chapter 19 (E & M)-23

Deferred Update in concurrent user system (3)

(a) T1 read_item (A) read_item (D) write_item (D) T2 read_item (B) write_item (B) read_item (D) write_item (D) T3 read_item (A) write_item (A) read_item (C) write_item (C) T4 read_item (B) write_item (B) read_item (A) write_item (A)

(b) [start_transaction, T1] [write_item, T1, D, 20] [commit, T1] [checkpoint] [start_transaction, T4] [write_item, T4, B, 15] [write_item, T4, A, 20] [commit, T4] [start_transaction T2] [write_item, T2, B, 12] [start_transaction, T3] [write_item, T3, A, 30] [write_item, T2, D, 25] system crash T2 and T3 are ignored because they did not reach their commit points. T4 is redone because its commit point is after the last checkpoint.

Yugma Kumar Agrawal

Chapter 19 (E & M)-24

Database Recovery based on Immediate Update When a transaction issues an update command, the database is updated immediately without waiting for the transaction to reach its commit point. The update operation is recorded into the log before it is applied to the database. The effects of the update operations of failed transactions is undone by rolling back the transaction.

Yugma Kumar Agrawal

Chapter 19 (E & M)-25

Immediate update in single user system Two list of transaction is maintained by the system: the committed transactions since the last checkpoint and the active transactions. Undo all the write_item operations of the active transactions from the log. Redo the write_item operations of the committed transactions from the log, in the order in which they were written in the log.

Yugma Kumar Agrawal

Chapter 19 (E & M)-26

Immediate update in concurrent user system

The recovery procedure depends on the protocol used for concurrency control. Procedure Use two lists of transactions maintained by the system : the committed transactions since the last checkpoint and the active transactions. Undo all the write_item operations of the active transactions from the log. The operations should be undone in the reverse order of the order in which they were written into the log. Redo the write_item operations of the committed transactions from the log, in the order in which they were written in the log.
Yugma Kumar Agrawal

Chapter 19 (E & M)-27

Immediate update in concurrent user system (3)

(a) T1 read_item (A) read_item (D) write_item (D) T2 read_item (B) write_item (B) read_item (D) write_item (D) T3 read_item (A) write_item (A) read_item (C) write_item (C) T4 read_item (B) write_item (B) read_item (A) write_item (A)

(b) [start_transaction, T1] [write_item, T1, D,15, 20] [commit, T1] [checkpoint] [start_transaction, T4] [write_item, T4, B, 15] [write_item, T4, A,25, 20] [commit, T4] [start_transaction T2] [write_item, T2, B, 12] [start_transaction, T3] [write_item, T3, A,10, 30] [write_item, T2, D,30, 25] system crash All the write_item operations of T2 and T3 are undone because they did not reach their commit points. T4 is redone because its commit point is after the last checkpoint. Yugma Kumar Agrawal

Chapter 19 (E & M)-28

Class Exercise 1
1. Write the log file entries for the following schedule
Transaction 1 read(A) A=A-10 A=A+10 B=B*1.1 write(A) Commit read(B) B=B-25 write(B) write(B) Commit write(A)
Chapter 19 (E & M)-29

Transaction 2 read(A)

Transaction 3 read(B)

Yugma Kumar Agrawal

Class Exercise 2

Suppose that the system crashes after the read(B) operation of transaction T2. What actions will be taken by the recovery manager in the case of deferred update and immediate update.

Yugma Kumar Agrawal

Chapter 19 (E & M)-30

Shadow Paging
The AFIM does not overwrite its BFIM but recorded at another place on the disk. Thus, at any time a data item has AFIM and BFIM (Shadow copy of the data item) at two different places on the disk.

Y X' Database

Y'

X and Y: Shadow copies of data items X` and Y`: Current copies of data items
Yugma Kumar Agrawal

Chapter 19 (E & M)-31

Shadow Paging
The database is considered to be made of fixed-size pages. A directory is constructed where the ith entry points to the ith page. When a transaction starts the current directory is copied into a shadow directory. The shadow directory is saved on the disk while the current directory is used by the transaction. During transaction execution the shadow directory is never modified. A new copy of the modified page is created The current directory entry is modified to point to the new disk block. The shadow directory is not modified and still point to the old unmodified block.

Yugma Kumar Agrawal

Chapter 19 (E & M)-32

Shadow Paging
For recovery the modified database page is freed and the current directory is discarded The shadow directory is containing the state of the database before transaction failure, and this state is recovered by reinstating the shadow directory.

Yugma Kumar Agrawal

Chapter 19 (E & M)-33

Shadow Paging
Current Directory (after updating pages 2, 5) 1 2 3 4 5 6 Shadow Directory (not updated) 1 2 3 4 5 6

Page 5 (old) Page 1 Page 4 Page 2 (old) Page 3 Page 6 Page 2 (new) Page 5 (new)

Yugma Kumar Agrawal

Chapter 19 (E & M)-34