Switch off your Mobiles Phones or Change Profile to Silent Mode

Database Recovery

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

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 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

Oracle Architecture Password file Instance SGA Redo Log Buffer Shared Pool Data Dictionary Cache Library Cache DBWRSMONPMONCKPTLGWROthers User process Server process PGA Control files Datafiles Database Database Buffer Cache Redo Log files Java Pool Large Pool Parameter file Archived Log files

Recovery – Basic Steps Database is archived periodically (back- up on disk / tape) Use Log or Journal file to record any change to database. 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 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 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 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

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 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 Transition 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 Disk corrupt, unreadable

Three Types of Failure System Failure (Soft Crash) to Volatile Storage Affecting all transactions currently in progress but no damage to database 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

Recovery – System Failure System Failure will affect all transactions currently in progress but not database itself System recovery is carried out as part of system’s restart procedure There are three main techniques used for recovery from System Failures Deferred Update Immediate Update Shadow Paging

Key Point about System Failure System Failure results in lost of contents of main memory (database buffer) Any transaction in progress at time of failure can no longer be successfully completed. So these transactions must be undone (rollback) when system restarts At restart time, it might also be necessary to redo certain transactions which did successfully complete before failure but did not manage to get their updates transferred from database buffers to database itself

Checkpoint & Checkpoint Record Log file contains Checkpoint Records At certain prescribed intervals system takes a Checkpoint. At Checkpoint, system Physically writes (force writing) contents of database buffers to physical database Physically writes a special checkpoint record to log Checkpoint record gives a list of all transactions in progress at time checkpoint was taken

Deferred Update Under this Recovery Protocol, updates (changes) are not written to database until after transaction has reached its Commit point If a transaction fails before reaching its commit point, Database will not be modified, nothing needs to be UNDONE If system failure occurs after commit point, it may still be necessary to REDO updates of committed transaction as its effect may not have reached database

Immediate Update Under this Recovery Protocol, updates (changes) are written to database immediately without waiting to reach Commit point Following a failure, system should UNDO updates made by transaction which had not committed at time of failure It may still be necessary to REDO updates of committed transactions

Immediate Update Key operations Check most recent checkpoint record when recovering from system crash Redo all work done by transactions which completed successfully before crash Undo all work done by transactions which started but did not complete before crash

Immediate Update General procedure – an outline On restart find checkpoint record from restart file Start with UNDO list and REDO list Set UNDO equal to list of all transactions given in most recent checkpoint record and set REDO to empty Search forward through log starting at checkpoint If a Begin-Transaction is found, put that transaction in UNDO list

Immediate Update If commit is found, move that transaction from UNDO list to REDO list At end of log, REDO list and UNDO list are completed Work backward through log undoing all transaction in UNDO list Work forward through log redoing all transaction in REDO list

Immediate Update – Example

Summary of operation for example After forward search of log Therefore, work backward to UNDO T3 and T5 Then work forward to REDO T2 and T4

Immediate Update – Summary

Consider various transactions in case Question Which transaction(s) need to be undone, redone or done nothing

Immediate Update – Summary Answer REDO–T2, T4 UNDO– T3, T5 Do nothing– T1

Shadow Paging This is an alternative scheme to log based recovery schemes DBMS keeps more than one copy of data item on disk This is in contrast to one place update approach where DBMS keeps only one copy of each data item on disk. Consequently, each time a new value of data item is written to disk, its old value is destroyed (replaced)

Shadow Paging – Key Points Shadow Copies We can choose to keep more than one copy of data item so that new value of data item may be written to disk without destroying old value. Old versions are called shadow copies Two Page Tables (Directories) A Page Table (directory) is used pointing at data items Each entry in page table gives name and position of each data item in disk

Shadow Paging – Key Points We need to keep two page tables to reflect shadow paging Therefore, each page table defines a different state of database; before and after updates Current Page Table & Shadow Page Table Current Page Table: New values Shadow Page Table: Old values

Shadow Paging – Key Points At start of a transaction, two tables are set to be same Then Shadow Page Table never changes during course of transaction, but can be used to restore database should a failure occur Current Page Table records all updates When transaction commits, Current Page Table becomes ‘new’ Shadow Page Table

Shadow Paging – Example

Shadow Paging Advantages Overhead of maintaining log file is eliminated System recovery is faster as there is no need for UNDO or REDO Disadvantages Increased data fragmentation on disk (reduced level of data clustering) Need for periodic ‘garbage’ collection or compaction to reclaim fragmented and hence ‘inaccessible’ data blocks on disk

Recovery – Datafile Lost/Corrupt

Any Questions?