Academic Year 2014 Spring

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

Recovery Types (continued) :

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

Different types of Media:

Stable Storage:

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)

Example – Transaction Failure:

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

Example – Media Failure:

Thank you!!! Questions are WELCOME Academic Year 2014 Spring