0% found this document useful (0 votes)
18 views9 pages

Assign

The document discusses failure classification in database management systems, outlining types of transaction failures, system errors, and disk failures. It explains recovery mechanisms, particularly log-based recovery, which maintains a sequence of records for transactions to ensure atomicity and consistency. Additionally, it covers the concept of checkpoints, which help manage logs during recovery by categorizing transactions into undo and redo lists based on their state at the checkpoint.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views9 pages

Assign

The document discusses failure classification in database management systems, outlining types of transaction failures, system errors, and disk failures. It explains recovery mechanisms, particularly log-based recovery, which maintains a sequence of records for transactions to ensure atomicity and consistency. Additionally, it covers the concept of checkpoints, which help manage logs during recovery by categorizing transactions into undo and redo lists based on their state at the checkpoint.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Advanced Database

Management System
Co-318
Assignment on
Failure Classification
Submitted by:
Ankush Kumar Singh Submitted to:
(2K22/SE/25) Dr. Indu Singh
Ritvik Vashishtha Assistant Professor
(2K22/CO/373) Department of Computer
Science and Engineering
TABLE OF CONTENTS
Failure Classification
Recovery And Atomicity
Log Based Recovery
Checkpoints
FAILURE CLASSIFICATION
Transaction failure:
Logical errors: transaction cannot complete due to some internal error condition
System errors: the database system must terminate an active transaction due to an error
condition (e.g., deadlock)
System crash: a power failure or other hardware or software failure causes. the system to
crash.
Disk failure: a head crash or similar disk failure destroys all or part of disk storage
Destruction is assumed to be detectable: disk drives use checksums to detect failures
RECOVERY AND ATOMICITY

To ensure atomicity despite failures, we first output information describing the


modifications to stable storage without modifying the database itself.

log-based recovery mechanisms-

The log is a sequence of records. Log of each transaction is maintained in some stable
storage so that if any failure occurs, then it can be recovered from there.
If any operation is performed on the database, then it will be recorded in the log
LOG-BASED RECOVERY

A log is kept on stable storage.


- The log is a sequence of log records, and maintains a record of update
activities on the database.
When transaction 7, starts, it registers itself by writing a
<T start>log record
Before Texecutes write(X), a log record
<T, X, V is written, where V, is the value of X before the write (the old value), and V, is
the value to be written to X (the new value).
LOG-BASED RECOVERY
Shadow-copy and Shadow-paging
This is the method where all the transactions are executed in the primary memory or
the shadow copy of database.
Once all the transactions completely executed, it will be updated to the database.
if there is any failure in the middle of transaction, it will not be reflected in the
database. Database will be updated after all the transaction is complete.
CHECKPOINTS
The checkpoint is a type of mechanism where all the previous logs are removed from
the system and permanently stored in the storage disk.
Checkpoint declares a point before which the DBMS was in consistent state, and all the
transactions were committed.
The recovery system reads the logs backwards from the end to the last checkpoint.
It maintains two lists, an undo-list and a redo-list.
If the recovery system sees a log with <tn, start=""> and <tn, commit=""> or just <tn,
commit="">, it puts the transaction in the redo-list.
If the recovery system sees a log with <tn, start=""> but no commit or abort log found, it
puts the transaction in undo-list.
All the transactions in the undo-list are then undone and their logs are removed.
All the transactions in the redo-list and their previous logs are removed and then
redone before saving their logs
CHECKPOINTS
During recovery we need to consider only the most recent transaction T, that started
before the checkpoint, and transactions that started after 7
Scan backwards from end of log to find the most recent
<checkpoint L> record
Only transactions that are in L or started after the checkpoint need to be redone or
undone
Transactions that committed or aborted before the checkpoint already have all their
updates output to stable storage.
Some earlier part of the log may be needed for undo operations
Continue scanning backwards till a record <7, start is found for every transaction 7 in L.
Parts of log prior to earliest <7, start> record above are not needed for recovery, and can
be erased whenever desired
THANK YOU

You might also like