CATHOLIC DIOCESE OF NSUKKA
ST CHARLES COLLEGE, OPI
COURSE: DATA PROCESSING
TERM: SECOND
CLASS: SS 3
Instructor: Fr. Maximillian ONOYIMA
Email:
[email protected], 08135778491
Topic: CRASH RECOVERY
Crash Recovery
Definition
Crash recovery is the process by which a database is restored to a consistent and usable state
after a system failure. This is achieved by rolling back incomplete transactions and ensuring that
all committed transactions that were still in memory at the time of the crash are properly written
to disk. A database is said to have reached a point of consistency when it is in a stable and reliable
state after recovery. Given the critical role of databases in storing and managing essential
information, an efficient crash recovery mechanism is necessary to prevent data loss and
corruption.
Conditions That Can Result in Transaction Failure
Several conditions may cause a transaction to fail, necessitating crash recovery:
1. Power Failure: Unexpected power loss may abruptly shut down a database system,
leading to data inconsistencies. For example, if an ATM transaction is in progress and the
power goes off before completion, the database must determine whether to rollback or
finalize the transaction upon restart.
2. Hardware Failure: Issues such as memory corruption, disk crashes, CPU malfunctions, or
network failures can interrupt database operations. If a server hosting an e-commerce
website crashes due to overheating, transactions made just before the crash must be
carefully recovered to avoid duplicate charges or loss of sales records.
3. Operating System Errors: A system crash due to an OS bug or kernel panic can bring the
entire database down, leading to incomplete transactions. For instance, if an online
banking application is running and the OS crashes, the database recovery process must
ensure account balances are accurate and transactions are either fully processed or
discarded.
1
Introduction to ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)
ARIES is a robust and widely used recovery algorithm designed for databases that follow a no-
force, steal approach. It is employed by major database systems, including IBM DB2 and
Microsoft SQL Server.
The three core principles of ARIES are:
1. Write-Ahead Logging (WAL): Before any change is made to a database object, it must first
be logged. The log entry is written to stable storage before the actual modification is
applied. This ensures that in the event of a crash, the logs can be used to redo committed
transactions and undo incomplete ones.
2. Repeating History During Redo: When a system restarts after a crash, ARIES replays all
transactions recorded in the logs to return the system to its pre-crash state before
deciding which transactions to undo. This prevents inconsistencies, such as duplicate
order processing in an online store.
3. Logging Changes During Undo: While undoing transactions, all changes made during the
undo process are also logged to prevent the same incomplete transactions from being
incorrectly re-applied if the system crashes again during recovery.
Recovery Procedure After a Crash
Crash recovery in ARIES occurs in three distinct phases:
1. Analysis Phase: The system scans the transaction log to determine which transactions
were committed, which were in progress, and which must be undone. This phase ensures
that necessary information is collected before initiating recovery actions.
2. Redo Phase: This phase restores the database to its exact state at the time of the crash by
applying all committed transactions from the log. For example, if a bank transaction was
successfully completed but not written to the database due to a crash, the redo phase
ensures it is re-applied.
3. Undo Phase: This phase undoes any incomplete transactions to restore the database to a
consistent state. If a customer was transferring money between accounts but the
transaction was only partially completed, the undo phase ensures that either the entire
transaction is applied or the changes are rolled back.
Other Recovery-Related Data Structures
1. Write-Ahead Log Protocol (WAL): WAL ensures that modifications are first recorded in a
log before being applied to the database. This protocol guarantees atomicity (ensuring
transactions are all-or-nothing) and durability (ensuring committed transactions are not
lost).
2
2. Atomicity: A fundamental ACID property ensuring that a transaction is either fully
completed or fully undone. If an online shopping transaction fails after payment but
before order confirmation, atomicity ensures the payment is refunded or the order is
completed.
3. Durability: Ensures that once a transaction is committed, it remains so even in the event
of a crash. A successfully recorded hotel booking, for example, must not be lost due to an
unexpected failure.
4. Transaction Log: A transaction log (or journal) records all database changes to ensure ACID
compliance. If a financial system crashes, the logs can be used to reconstruct missing
transactions and validate existing ones.
5. Checkpointing: This technique periodically saves a snapshot of the database, reducing
recovery time. For example, a checkpoint might be taken every 10 minutes so that in the
event of a crash, recovery starts from the last checkpoint instead of the beginning of the
log.
6. Media Recovery: Deals with failures of permanent storage media such as hard disks. It
relies on backup copies and archive logs to restore the database. RAID (Redundant Arrays
of Independent Disks) can help mitigate disk failures, but does not eliminate the need for
media recovery solutions.
Conclusion
Crash recovery is an essential aspect of database management, ensuring data integrity and
system stability in the event of failures. ARIES and its associated recovery mechanisms help
databases recover efficiently while preserving consistency and durability. By leveraging write-
ahead logging, redo and undo procedures, checkpointing, and media recovery, modern
database systems can handle unexpected crashes with minimal data loss and downtime.
Understanding these principles is crucial for database administrators and system architects
responsible for maintaining robust and reliable database environments.
