MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 1) Academic Year 2014 Spring
Recovery – Definition: Database Recovery: (C J Date) To “restore database to a stable that is known to be correct after some failure has rendered current state incorrect or at least suspect ” Underlying principles for handling database recovery: redundancy. By applying this principle any piece of information can be recovered from some other information stored, redundantly, somewhere else in system.
Recovery Types: Complete Recovery Brings database up to present, including all committed data changes made to point in time when recovery was requested Incomplete Recovery Brings database up to a specified point in time in past, before recovery operation was requested
Storage Media: Different types of Storage Media and their resilience to failure Volatile Storage (VS): Information does not survive system crashers e.g. Main and Cache Memory Non Volatile Storage (NVS): Information usually survives system crashers but not hardware ‘corruption’ e. g. Disks (Online NVS) and Magnetic tape (Offline NVS)
Storage Media (continued) : Stable Storage (SS) Several non volatile storage media with independent failure nodes having information replicated on them and adopting a careful replacement strategy for updates - information is ‘never’ lost
Recovery – Basic Steps: 1.Database is ARCHIVED periodically (back-up on disk / tape) 2.Use LOG or JOURNAL FILE to record any change to database. 3.When a failure occurs, use ARCHIVE and LOG to REDO or UNDO changes
LOG Files: To keep track of Database Transactions, DBMS maintains a Log (Journal) file, which contains information about all updates to database. Log file contains transaction records and checkpoint records and other relevant information
LOG Files (continued) : Transaction records contain ID of transaction ID of record to be accessed Type of operation (Insert, Delete, Modify) Old value of record New value of record Other relevant information
Transactions: Issue of database recovery is related to concept of transaction processing Logical unit of work A transaction is independent of number of times program reads & writes to database Atomicity A database system which supports transaction processing ensures that a transaction (containing a sequence of operations) either executes in its entirely or totally cancelled
Transactions (continued) : Operation Key to support of atomicity is provision of following operations of a transaction Begin-Transaction Initiates an Transaction Commit Signals successful End-of-Transaction. All updates made by this transaction can be committed or made permanent Rollback Signals unsuccessful End-of-Transaction. All updates made by this transaction so far must be rolled back or undone
Transactions (continued) : Unit of Recovery A transaction is both a logical unit of work and a logical unit of recovery Log and Journal file Details of all updates are written on log file which is maintained by system. This makes it possible for system to undo or redo an update
ACID Properties of Transaction: Atomicity All actions happen, or none happen. Consistency (Correctness) If Database starts consistent, it ends up consistent. Isolation Transactions are isolated from one another Durability Once a transaction commits, its updates persist
Recovery Manager: Recovery Manager of database needs to keep track of information Begin-Transaction Start of a transaction Read/Write Operations on database End-Transaction Signals end of read/write operations Commit-Transaction Successful end of a transaction and all updates can be committed to database and will not be undone
COMMIT Point: Commit establishes a Commit Point (also called synchpoint) A Commit Point corresponds to end of a logical unit of work (a point at which database is or should be in consistent state) Prior to Commit Point all updates by transaction should be regarded as tentative only (might be undone subsequently). Once committed an update is guaranteed never to be undone subsequently). Once committed however, an update is guaranteed never to be undone.
BUFFERING and COMMIT: However, situation is complicated by fact that update to database is not and atomic (single step) action Database operation take place using Database Buffers in main memory from which data is transferred to & from disk. When buffers have been flushed to disk then only updates can be considered as permanent. This flushing can be triggered by a specific command (commit) or automatically when buffers become full.
BUFFERING and COMMIT (continued) : It is therefore possible for a transaction to have committed but for its effects not to have been permanently recorded in database, simply because they have not yet reached database.
Recovery Techniques: Some Recovery Techniques Rollback Due to unsuccessful end to a transaction, all changes made during course of transaction must be undone Undo Similar to Rollback, but could mean to apply to a single operation Redo Operation must be carried out to ensure all updates of committed transaction have been applied successfully to database
State Transaction Diagram for Transaction Execution:
Transaction System: System supporting transaction processing guarantees that if a transaction executes some database updates and program failure occurs before transaction is completed, all updates carried out will be undone. Permanent database is restored to original state (before transaction began)
Three Types of Failure: There are generally three types of failure in a database system Transaction Failure Transaction fails to complete (as a result of program or data failure) Media Failure (Hard Crash) to non Volatile Storage Damage to (part of) a database (e.g. disk corrupt, unreadable) System Failure (Soft Crash) to Volatile Storage Affecting all transactions currently in progress but no damage to database (e.g. Power Failure causing lost of data in main memory)
Recovery – Transaction Failure: Key Points Rollback transaction UNDO all updates Go backwards through log file Identify failed transaction Take old values from log Writing it back to disk Ensure log is written to disk before updates are written to database (write ahead log protocol)
Recovery – Media Failure: Key Points Restore database from a previous archive Use log to REDO Go backwards through log noting all committed transactions Go forward through log redoing all committed transactions Ignore Rollback and in progress transactions Ensure that log is written to disk before changes (updates) are made to disk