Scribd
Upload
17 views

Chapter 5 DBRecovery

Uploaded by

misrak dagne
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
17 views

Chapter 5 DBRecovery

Uploaded by

misrak dagne
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 23

Outline

Database Recovery ?
Types of failure ?
Basic Steps in recovery ?
Recovery facilities .
Recovery Techniques .
Focusing on Recovery
 All database reads/writes are within a transaction
 Transactions have the “ACID” properties
 Atomicity - all or nothing
 Consistency - preserves database integrity
 Isolation - execute as if they were run alone
 Durability - results aren’t lost by a failure
 Recovery subsystem guarantees A & D
 Concurrency control guarantees I
 Application program guarantees C
Database Recovery
• What is Recovery?
– the process of getting back something lost(dictionary
definition)
• What is Database Recovery?
– is the process of restoring the database to the most
recent consistent state that existed just before the
failure.
Why 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.
Types of failure
• The database may become inconsistent or unavailable for
use due to various types of failure:
• 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.
• How to control this failures?
Recovery Concept (Sample log)

T ID Back P Next P Operation Data item BFIM AFIM


T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End
Recovery Concept cont…
 Data Caching(Buffering) of Disk Blocks
 The recovery process is often closely intertwined with
operating system functions.
 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 Modified and Pin-Unpin
bits.
• Pin-Unpin: Instructs the operating system not to
flush the data item. it cannot be written back to disk
as yet.
• Modified: Indicates the AFIM of the data item.
Recovery Concepts(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(in order to undo or redo).
 This is achieved by Write-Ahead Logging (WAL) protocol.
 Information needed to Redo:
 A REDO-type log entry includes the new value (AFIM) of
the item written by the operation.
 Since this is needed to redo the effect of the operation
from the log (by setting the item value in the database
on disk to its AFIM).
The basic steps in
performing a recovery are
Isolating the database from other users.
Occasionally, you may need to drop and re-
create the database to continue the
recovery.
Restoring the database from the most recent
useable dump.
Applying transaction log dumps, in the
correct sequence, to the database to make
the data as current as possible.
Cont…
It is a good idea to test your backup and recovery
plans periodically by loading the backups and
transaction logs into a test database and verifying
that your procedure really works.
One can recover databases after three basic types
of problems: user error, software failure, and
hardware failure.
The database recovery manger is responsible to
guarantee the atomicity and durability properties of
the ACID property.
Exmples
The execution of a transaction T is correct if, given
a consistent database; T leaves the database in
the next consistent state.
 Initial consistent state of the database: S1. T
changes the consistent state from S1 to S2.
During this transition the database may go into an
inconsistent state, which is visible only to T.
If the system or T fails then database will not be
able to reach S2, consequently the visible state
would be an inconsistent state. From this state we
can go either forward (to state S2) or go backward
Given Transaction Exmple2
Time Operation

1 A=A+200

2 B=B-100

3 C=C-200

Failure

4 A=A+200

5 B=B+700

6 C=C+600
Cont…
Recovery Facilities
Backup mechanism: that makes periodic
backup copies of database.
Logging facility: that keeps track of current
state of transactions and database changes.
Checkpoint facility: that enables updates to
database in progress to be made permanent.
Recovery manger : which allows DBMS to
restore the database to a consistent state
following a failure.
Such kind of information is stored in a system log
or transaction log file.
Log File
Log File
 Contains information about all updates to
database:
 Transaction records.
 Checkpoint records.
Log file example
Recovery Techniques
Damage to the database could be either physical
and relate which will result in the loss of the data
stored or just inconsistency of the database state
after the failure. For each we can have a recover
mechanism:
Cont…
If database has been damaged:
 Need to restore last backup copy of database
and reapply updates of committed transactions
using log file.
 Extensive damage/catastrophic failure: physical
media failure; is restored by using the backup
copy and by re executing the committed
transactions from the log up to the time of
failure.
Cont…
If database is only inconsistent:
No physical damage/only inconsistent: the restoring is
done by reversing the changes made on the database
by consulting the transaction log.
Need to undo changes that caused inconsistency. May
also need to redo some transactions to ensure updates
reach secondary storage.
Do not need backup, but can restore database using
before- and after-images in the log file.
Recovery Techniques
Three main recovery techniques:
 Deferred Update
 Immediate Update
 Shadow Paging
Deferred Update
Updates are not written to the database until after a
transaction has reached its commit point.
If transaction fails before commit, it will not have
modified database and so no undoing of changes
required.
May be necessary to redo updates of committed
transactions as their effect may not have reached
database.
NO-UNDO/REDO Algorithm
Immediate Update/ Update-In-Place
 Updates are applied to database as they occur.
 Need to redo updates of committed transactions following
a failure.
 May need to undo effects of transactions that had not
committed at time of failure.
 Essential that log records are written before write to
database. Write-ahead log protocol.
 If no "transaction commit" record in log, then that
transaction was active at failure and must be undone.
 UNDO/REDO Algorithm.
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.

You might also like