Recovery System
Recovery System
Recovery System
DBMS
Outline
• Recovery?
• Importance of Recovery
• Failure Classification
• Storage Structure
• Recovery and Atomicity
• Log-Based Recovery
• Remote Backup System
• Algorithm for Recovery and Isolation Exploiting Semantics
(ARIES)
• RAID (Left on the students)
What is Recovery?
• It is the process of restoring the db to most recent
consistent state that existed just before the failure.
• It is the responsibility of recovery manager/
recovery management component.
• 3 states of database recovery
– Pre-condition {consistent state}
– Condition {failure occur}
– Post-condition {restoring the db to most recent
consistent state that existed just before the failure}
Why Recovery is important?
• A DBMS has to ensure ACID properties even in the
case, a transaction fail due to system crash or failure
– Mainly atomicity and durability.
– Otherwise DB may lead to inconsistent state
• How to recover?
– Backup and restore
– Recovery algorithms
• An integral part of a database system is a recovery
scheme that can restore the database to the
consistent state that existed before the failure.
Failure Reason
• System failure occur due to variety of reasons
such as disk crash, power outage, software
error, hardware error, a fire in the machine
room, even sabotage.
Failure Classification
• Transaction failure :
– Logical errors: The transaction can no longer continue with its normal execution because
of some internal condition, such as bad input, data not found, overflow, or resource limit
exceeded.
– System errors: The system has entered an undesirable state (for example, deadlock), as a
result of which a transaction cannot continue with its normal execution. The transaction,
however, can be re-executed at a later time.
• System crash: a power failure or other hardware or software failure causes the
system to crash.
– Fail-stop assumption: The assumption that hardware errors and bugs in the software
bring the system to a halt, but do not corrupt the nonvolatile storage contents, is known
as the fail-stop assumption. Non-volatile storage contents are assumed to not be
corrupted by system crash.
• Database systems have numerous integrity checks to prevent corruption of disk data
• Disk failure: A disk block loses its content as a result of either a head crash or
failure during a data-transfer operation.
Recovery algorithms
• To determine how the system should recover
from failures, we need to identify the failure
modes of those devices used for storing data.
• Next, we must consider how these failure
modes affect the contents of the database.
• We can then propose algorithms to ensure
database consistency and transaction
atomicity despite failures.
Recovery algorithms
• Recovery algorithms, have two parts:
1. Precondition: Actions taken during normal transaction
processing to ensure that enough information exists to
allow recovery from failures.
2. Postcondition: Actions taken after a failure to recover
the database contents to a state that ensures database
consistency, transaction atomicity, and durability
• The recovery scheme must provide high availability;
that is, it must minimize the time for which the
database is not usable after a failure.
Recovery and Atomicity
• When a DBMS recovers from a crash, it should
maintain the following −
– It should check the states of all the transactions, which
were being executed.
– A transaction may be in the middle of some operation; the
DBMS must ensure the atomicity of the transaction in this
case.
– It should check whether the transaction can be completed
now or it needs to be rolled back.
– No transactions would be allowed to leave the DBMS in an
inconsistent state
Recovery and Atomicity
• There are two types of techniques, which can
help a DBMS in recovering as well as
maintaining the atomicity of a transaction −
– Maintaining the logs of each transaction, and
writing them onto some stable storage before
actually modifying the database.
– Maintaining shadow paging, where the changes
are done on a volatile memory, and later, the
actual database is updated.
Log-based Recovery
• The most widely used structure for recording db
modification is the log.
• Log is a sequence of records
– Which maintains the records of actions performed by a
transaction.
• It contains information about the start and end of each transaction
and any updates which occur in the transaction.
• The log keeps track of all transaction operations that affect the values
of database items.
– It is important that the logs are written prior to the actual
modification and stored on a stable storage media, which is
failsafe.
Log-based recovery
• Log-based recovery works as follows −
– The log file is kept on a stable storage media.
– When a transaction enters the system and starts
execution, it writes a log about it.
– At the time of a system crash, item is searched back
in the log for all transactions T that have written a
start_transaction(T) entry into the log but have not
written a commit(T) entry yet; these transactions
may have to be rolled back to undo their effect on
the database during the recovery process.
Log-based recovery: Log update fields
• Transaction identifier
– which is the unique identifier of the transaction that performed the
write operation.
• Data-item identifier
– which is the unique identifier of the data item written. Typically, it is
the location on disk of the data item, consisting of the block
identifier of the block on which the data item resides, and an offset
within the block.
• Old value
– which is the value of the data item prior to the write.
• New value
– which is the value that the data item will have after the write.
Log-based recovery: Log update fields
• start_transaction(Ti): This log entry records that transaction T starts
the execution.
• read_item(Ti, Xi): This log entry records that transaction T reads the
value of database item X
• write_item(Ti, Xi, old_value, new_value): This log entry records that
transaction T changes the value of the database item X from
old_value to new_value. The old value is sometimes known as a
beforeimage of X, and the new value is known as an afterimage of X.
• commit(Ti): This log entry records that transaction T has completed
all accesses to the database successfully and its effect can be
committed (recorded permanently) to the database.
• abort(Ti): This records that transaction T has been aborted.
Log-based recovery: Log update fields
Log-based recovery: database update strategies
A’s Account
New_Balance = Old_Balance – 100
Close_Account(A)
B’s Account
New_Balance = Old_Balance + 100
Close_Account(B)
Shadow Paging (No Undo and No Redo)
Shadow Paging (No Undo and No Redo)
Shadow Paging (No Undo and No Redo)
Shadow Paging (No Undo and No Redo)
• copy-on-write technique.
• A directory is getting created
– It contains block no and pointer to each block
• Create the shadow of the directory
– Copy in the disk
• Start the transaction
– Transfer block A to main memory
– Then reduce 100 there
– write that back to the disks to new location
– Current directory now point to new location
– Transfer block B to main memory
– Then add100 there
– write that back to the disks to new location
– Current directory now point to new location
• If Transaction commit
– Discard shadow directory
– The blocks which are not pointed by current directory are de-allocated
• If Transaction fails
– Discard current directory
Shadow Paging (No Undo and No Redo)
Shadow Paging (No Undo and No Redo)
Shadow Paging (No Undo and No Redo)
Drawbacks of shadow-paging