Chapter 23 Data Recovery

Question 1

Purpose of Database Recovery

Answer 1

To bring the database into the last consistent state which existed prior to the failure. To preserve transaction properties.

Question 2

Types of failure

Answer 2

transaction failure
system failure
media failure

Question 3

transaction failure

Answer 3

transactions may fail because of incorrect input, deadlock, incorrect synch.

Question 4

System failure

Answer 4

System may fail because of addressing error, application error,, operating system fault, RAM failure

Question 5

Media failure

Answer 5

Disk head Crash , power disruption

Question 6

Transaction log

Answer 6

for recovery from any failure requires value prior to modification (BeFore IMage) and after modification(AFter IMage). these values are stored in a seq file called the transaction log.

Question 7

data update

Answer 7

Immediate update
Deffered update
Shadow update
in-place update

Question 8

Immediate Update

Answer 8

As soon as a data item is modified in cache, the disk copy is updated

Question 9

Defered update

Answer 9

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

Question 10

Shadow update

Answer 10

the mod. version of a data item doesnt overwrite its disk copy but is written at a separate disk location

Question 11

Data caching

Answer 11

data items are stored into the database by the cache manage then written into the disk after modification. flushing is controlled by modified and pin-unpin bits.

Question 12

Pin-unpin bits

Answer 12

instructs the OS not to flush the data item.

Question 13

Modified bits

Answer 13

Indicates the AFIM of the data item.

Question 14

trans. rollback(UNDO)

Answer 14

restore all BFIMS on to disk (Removes the AFIMS)

Question 15

trans rollback(REDO)

Answer 15

Restore all AFIMS on to the disk

Question 16

in-place update

Answer 16

The disk version of the data item is overwritten by the cache version

Question 17

Checkpointing

Answer 17

Time to time (randomly or under some criteria) the database flushes its buffer to database disk to minimize the task of recovery.

Question 18

steps defines a checkpoint operation

Answer 18

1. Suspend execution of transactions temporarily.
2. Force write modified buffer data to disk.
3. Write a [checkpoint] record to the log, save the log to disk.
4. Resume normal transaction execution.

Question 19

Possible ways for flushing database cache to database disk:

Answer 19

Steal/No-Steal and Force/No-Force

Question 20

Steal:

Answer 20

Cache can be flushed before transaction commits

Question 21

No-Steal

Answer 21

Cache cannot be flushed before transaction commit.

Question 22

Force

Answer 22

Cache is immediately flushed (forced) to disk.

Question 23

No-Force

Answer 23

: Cache is deferred until transaction commits.

Question 24

four different ways for handling recovery

Answer 24

Steal/No-Force (Undo/Redo), Steal/Force (Undo/No-redo), No-Steal/No-Force (Redo/No-undo) and No-Steal/Force (No-undo/No-redo).

Question 25

Deferred Update (No Undo/Redo)

Answer 25

The data update goes as follows:
1. A set of transactions records their updates in the log.
2. At commit point under WAL scheme these updates are saved on database disk.
After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits.

Question 26

Deferred Update in a single-user system

Answer 26

The data update goes as follows:
1. A set of transactions records their updates in the log.
2. At commit point under WAL(write ahead logging) scheme these updates are saved on database disk.
After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits.

Question 27

Deferred Update with concurrent users

Answer 27

This environment requires some concurrency control mechanism to guarantee isolation property of transactions.
In a system recovery transactions which were recorded in the log after the last checkpoint were redone.
The recovery manager may scan some of the transactions recorded before the checkpoint to get the AFIMs.

Question 28

Deferred Update with concurrent users table types:

Answer 28

Two tables are required for implementing this protocol:

Active table: All active transactions are entered in this table.
Commit table: Transactions to be committed are entered in this table.

Question 29

active tables and conc. tables recovery process

Answer 29

During recovery, all transactions of the commit table are redone and all transactions of active tables are ignored since none of their AFIMs reached the database.

Question 30

Undo/No-redo Algorithm

Answer 30

In this algorithm AFIMs of a transaction are flushed to the database disk under WAL before it commits. For this reason the recovery manager undoes all transactions during recovery. No transaction is redone.

Question 31

Undo/Redo Algorithm (Single-user environment)

Answer 31

Recovery schemes of this category apply undo and also redo for recovery. In a single-user environment no concurrency control is required but a log is maintained under WAL.

Question 32

Recovery manager actions in Undo/Redo Algorithm (Single-user environment)

Answer 32

The recovery manager performs:

Undo of a transaction if it is in the active table.
Redo of a transaction if it is in the commit table.

Question 33

Undo/Redo Algorithm (Concurrent execution)

Answer 33

In concurrent execution environment a concurrency control is required and log is maintained under WAL. Commit table records transactions to be committed and active table records active transactions.

Question 34

Recovery manager actions in Undo/Redo Algorithm (concurrent execution)

Answer 34

The recovery performs:

Undo of a transaction if it is in the active table.
Redo of a transaction if it is in the commit table.

Question 35

Shadow Paging

Answer 35

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.

Question 36

ARIES Recovery Algorithm based on

Answer 36

1. WAL (Write Ahead Logging)
2. Repeating history during redo: ARIES will retrace all actions of the database system prior to the crash to reconstruct the database state when the crash occurred.
3. Logging changes during undo: It will prevent ARIES from repeating the completed undo operations if a failure occurs during recovery, which causes a restart of the recovery process.

Question 37

ARIES recovery algorithm consists of three steps:

Answer 37

Analysis, Redo, Undo

Question 38

Aries Analysis Step

Answer 38

step identifies the dirty (updated) pages in the buffer and the set of transactions active at the time of crash.

Question 39

Aries REdo Step

Answer 39

necessary redo operations are applied.

Question 40

Aries Undo Step

Answer 40

log is scanned backwards and the operations of transactions active at the time of crash are undone in reverse order.

Question 41

Log Record Use

Answer 41

A log record is written for (a) data update, (b) transaction commit, (c) transaction abort, (d) undo, and (e) transaction end.

Question 42

Log Sequence Number (LSN)

Answer 42

unique number associated with every log, indicates where the log is in the disk

Question 43

A log record stores:

Answer 43

Previous LSN of that transaction: It links the log record of each transaction. It is like a back pointer points to the previous record of the same transaction.

Transaction ID

Type of log record.

Question 44

For a write operation a log record also logs

Answer 44

Page ID for the page that includes the item

Length of the updated item

Its offset from the beginning of the page

BFIM of the item

AFIM of the item

Question 45

Transaction table

Answer 45

Contains an entry for each active transaction, with information such as transaction ID, transaction status and the LSN of the most recent log record for the transaction.

Question 46

Dirty Page table

Answer 46

Contains an entry for each dirty page in the buffer, which includes the page ID and the LSN corresponding to the earliest update to that page.

Question 47

Checkpointing Steps

Answer 47

1. Writes a begin_checkpoint record in the log
2. Writes an end_checkpoint record in the log.
3. Writes the LSN of the begin_checkpoint record to a special file. This file is accessed in recovery to locate the checkpoint info

Question 48

ARIES Recovery Algorithm Steps

Answer 48

Analysis, Redo, Undo phases

Question 49

ARIES Recovery Algorithm Analysis

Answer 49

Analysis phase: Start at the begin_checkpoint record and proceed to the end_checkpoint record. Access transaction table and dirty page table are appended to the end of the log.

Question 50

ARIES Recovery Algorithm Redo phase

Answer 50

Starts from the point in the log up to where all dirty pages have been flushed, and move forward to the end of the log.

Question 51

ARIES Recovery Algorithm Undo phase

Answer 51

Starts from the end of the log and proceeds backward while performing appropriate undo. For each undo it writes a compensating record in the log.