Transcript Recovery - Computer Information Systems

Recovery
Backing Up Data
Recovery Plans
Overview
n
n
n
n
n
Transactions
Recovery
Transaction Recovery
Failure
Recovery Plans
Transactions
n
Concept: Logical unit of work and
logical unit of recovery
n
Definition: The execution of a
program that accesses or changes
the contents of the database.
Example Transaction
Transaction Support
n
Can have one of two outcomes:
n
n
n
n
n
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.
Transactions
n
n
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.
Transactions
n
n
Desirable Transaction Properties
ACID properties
n
n
Atomicity - All parts of a transaction must
be completed or aborted.
Consistency - Database transformed from
one consistent state to another consistent
state
n
Note: At intermediate steps database not
necxessarily consistent
n
n
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.
transaction’s updates concealed until
after commit.
Durability (permanency)- Indicates the
permanence of the database’s consistent
state. After commit, changes can’t be
lost.
Recovery
n
n
n
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
n
A database is correct iff it satisfies the
logical AND of all known rules
n
Failure - can be local or global
n
Transaction failures handled by:
n
n
n
application program
not explicitly handled by application
Categories of failures
n
system failures
n
n
n
affect all transactions but no physical damage
soft crash
Media failures
n
n
cause damage to transactions in portion of database
hard crash
Recovery Facilities
n
DBMS should provide following facilities
to assist with recovery:
n
n
n
n
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.
Transaction recovery
n
Transfer $500 from checking to savings given
original balances
n
n
n
Begin transaction
n
n
n
n
n
n
n
n
checking
$1000
savings $2000
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
Log File
n
Contains information
updates to database:
n
n
n
about
all
Transaction records.
Checkpoint records.
Often used for other purposes (for
example, auditing).
Log file
n
Transaction records contain:
n
n
n
n
n
n
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.
Transaction Log
After Image Log
Begin Transaction
T1
start
T1
checking balance
500
T1
savings balance
2500
T1
commit
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
Transaction Log
Before Image Log
Begin Transaction
T1 start
read checking balance
subtract $500 from checking balance T1
checking balance
1000, 500
write checking balance
read savings balance
add $500 to savings balance
T1
saving balance
2000, 2500
write savings balance
End transaction
Commit
T1 commit
Check[point
Checkpoint
Point of synchronization between database and log
file. All buffers are force-written to secondary
storage.
n
n
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.
Transactions in the Log
n
States
n
n
n
Read / Write
Commit / Abort
Checkpoints & Force Writes
n
n
n
n
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
System Failures
n
n
n
n
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?
Checkpoints
T1
T2
T3
T4
Time
T5
Check Point
System
Failure
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
Recovery Process
n
n
n
n
n
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.
Shadow Paging
n
n
n
n
n
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.
Recovery Plans
n
Variety of natural or human activities
can damage or render vital information
assets inoperable.
n
n
n
n
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?