Recovery

1
Recovery

• Backing Up Data
• Recovery Plans

2
Overview

• Transactions
• Recovery
• Transaction Recovery
• Failure
• Recovery Plans

3
Transactions

• Concept Logical unit of work and logical unit of
  recovery
• Definition The execution of a program that
  accesses or changes the contents of the database.

4
Example Transaction
5
Transaction Support

• Can have one of two outcomes
• Success - transaction commits and database
  reaches a new consistent state.
• Failure - transaction aborts, and database must
  be restored to consistent state before it
  started.
• Such a transaction is rolled back or undone.
• Committed transaction cannot be aborted.
• Aborted transaction that is rolled back can be
  restarted later.

6
Transactions

• Transforms database from one consistent state to
  another, although consistency may be violated
  during transaction
• Application program is series of transactions
  with non-database processing in between.

7
Transactions

• Desirable Transaction Properties
• ACID properties
• Atomicity - All parts of a transaction must be
  completed or aborted.
• Consistency - Database transformed from one
  consistent state to another consistent state
• Note At intermediate steps database not
  necxessarily consistent

8

• Isolation - Actions are not visible to other
  transactions until it is committed. Data used
  during execution of transaction cannot be used by
  second transaction until first one is completed,
  i.e. transactions updates concealed until after
  commit.
• Durability (permanency)- Indicates the permanence
  of the databases consistent state. After commit,
  changes cant be lost.

9
Recovery

• If nothing ever goes wrong there is no need for
  recovery.
• Recovery - restoring the database to a state that
  is known to be correct after some failure has
  rendered the current state incorrect.
• Correct - does not violate any integrity rule
• A database is correct iff it satisfies the
  logical AND of all known rules

10

• Failure - can be local or global
• Transaction failures handled by
• application program
• not explicitly handled by application
• Categories of failures
• system failures
• affect all transactions but no physical damage
• soft crash
• Media failures
• cause damage to transactions in portion of
  database
• hard crash

11
Recovery Facilities

• DBMS should provide following facilities to
  assist with recovery
• Backup mechanism, which makes periodic backup
  copies of database.
• Logging facilities, which keep track of current
  state of transactions and database changes.
• Checkpoint facility, which enables updates to
  database in progress to be made permanent.
• Recovery manager, which allows DBMS to restore
  the database to a consistent state following a
  failure.

12
Transaction recovery

• Transfer 500 from checking to savings given
  original balances
• checking 1000
• savings 2000
• Begin transaction
• read checking balance
• subtract 500 from checking balance
• write checking balance
• read savings balance
• add 500 to savings balance
• write savings balance
• End transaction
• Commit

13
Log File

• Contains information about all updates to
  database
• Transaction records.
• Checkpoint records.
• Often used for other purposes (for example,
  auditing).

14
Log file

• Transaction records contain
• Transaction identifier.
• Type of log record, (transaction start, insert,
  update, delete, abort, commit).
• Identifier of data item affected by database
  action (insert, delete, and update operations).
• Before-image of data item.
• After-image of data item.
• Log management information.

15
Transaction Log After Image Log
16
Transaction Log Before Image Log
17
Checkpoint

• Checkpoint
• Point of synchronization between database and
  log file. All buffers are force-written to
  secondary storage.
• Checkpoint record is created containing
  identifiers of all active transactions.
• When failure occurs, redo all transactions that
  committed since the checkpoint and undo all
  transactions active at time of crash.

18
Transactions in the Log

• States
• Read / Write
• Commit / Abort
• Checkpoints Force Writes
• Suspend execution of transactions temporarily
• Force-write all update operations of committed
  transactions from main memory buffers to disk
• Write a record to the log and force-write the log
  to the disk
• Resume executing transactions

19
System Failures

• Contents of main memory (buffers) lost
• If precise state of transaction unknown, then
  transaction must be UNDONE
• If transaction completed but updates not
  transferred to disk, then transaction must be
  REDONE
• For each of the following transactions should the
  system do a REDO or UNDO?

20
Checkpoints
T1
T2
TRANSACTIONS
T3
T4
T5
Check Point
System Failure
Time
T1 - completed prior to check point T2 - started
prior to checkpoint, completed after checkpoint
but before crash T3 - started prior to
checkpoint, did not complete before crash T4 -
started after checkpoint, completed before
crash T5 - started after checkpoint, did not
complete before crash
21
Recovery Process

• Start with 2 lists of transactions, UNDO list and
  REDO list. Set UNDO list equal to list of all
  transactions given in the most recent checkpoint
  record set REDO list to empty
• Search forward through the log, starting from
  checkpoint record
• If a BEGIN TRANSACTION log entry found for
  transaction, T add T to UNDO list.
• If COMMIT log entry is found for transaction, T,
  move from UNDO list to REDO list.
• When end of log is reached, UNDO and REDO lists
  identify transactions to be undone and redone,
  respectively.

22
Shadow Paging

• Maintain two page tables during life of a
  transaction current page and shadow page table.
• When transaction starts, two pages are the same.
• Shadow page table is never changed thereafter and
  is used to restore database in event of failure.
• During transaction, current page table records
  all updates to database.
• When transaction completes, current page table
  becomes shadow page table.

23
Recovery Plans

• Variety of natural or human activities can damage
  or render vital information assets inoperable.
• Examples of natural disasters
• Examples of human error disasters
• Recovery plans deal with potential situations in
  which risk of loss varies from high to low
• What is necessary to put in a recovery plan?