Database Recovery - MetaLab

Document Sample
Database Recovery - MetaLab Powered By Docstoc
					 Mechanism for restoring a database quickly
  and accurately after loss or damage
 Recovery facilities:
  •   Backup Facilities
  •   Journalizing Facilities
  •   Checkpoint Facility
  •   Recovery Manager
   A DBMS COPY utility that produces a backup copy (save) of
    the entire database or a subset of the database
   Backup: not only the database files but also related database
    objects (repository, database indexes, source libraries, etc)
   Periodic backup (e.g. nightly, weekly)
   Backups stored in secure, off-site location
   Backup copy-used to restore the database
   Cold backup–database is shut down during backup
   Hot backup–selected portion is shut down and backed up at a
    given time
   Incremental backups: record changes made since the last
   Differential backups: record changes made since the last
    full/normal backup
       the differences since the last full backup.
   Database downtime can be very expensive
        The lost revenue needs to be balanced against the
         cost of additional technology, primarily disk
         storage, to achieve a desired level of availability
         To achieve: some DBMS automatically make
          backup copies in real time.
         Stored in on separate disk drives
   Audit trail of transactions and database changes
   In the event of failure: consistent database state
    can be reestablished using the information in
    the journals together with the most recent
    complete backup
   Two basic journals or logs:
       Transaction log–record of essential data for each
        transaction processed against the database
         Transaction code, action, time, terminal no/user ID,
         input data values , tables/records accessed & modified
         and the old & new field values.
       Database change log–images of updated data
         Before-image–copy of a record before modification
         After-image–copy of a record after modification
   A facility by which the DBMS periodically refuses to
    accept new transactions. The system is in a quiet state
    and the database and transaction logs are synchronized
   All transactions in progress are completed and journal
    files are brought up-to-date
   DBMS writes a special record (checkpoint record) to
    the log file: snapshot of the state of the database
   Checkpoint record contains information necessary to
    restart the system
   Any dirty data blocks (pages of memory that contain
    changes that have not yet been written out to disk) are
    written from memory to disk storage
   Automatically or response to commands in user
    application programs
   A module of the DBMS that restores the
    database to a correct condition when a failure
    occurs and then resumes processing user
   Type of restart used depends on the nature of
   Disk Mirroring–switch between identical
    copies of databases
   Restore/Rerun–reprocess transactions
    against the backup
   Transaction Integrity–commit or abort all
    transaction changes
   Backward Recovery (Rollback)–apply before
   Forward Recovery (Roll Forward)–apply
    after images (preferable to restore/rerun)
        Database must be mirrored  switch to an
         existing copy of the database
        2 copies of the database must be kept &
         updated simultaneously
        Media failure occurs: processing switch to the
         duplicate copy
        Allows fastest recovery

Recovery and Restart Procedures
        Involves reprocessing the day’s transactions
         (up to the point of failure) against the backup
         copy of the database
            Database is shut down
            The most recent copy of the database /file to be
             recovered is mounted
            All transactions that have occurred since that copy
             (stored on the transaction log) are rerun

Recovery and Restart Procedures
        Advantage:
            Simplicity
              DBMS does not need to create a database change journal &
               no special restart procedures required
        Disadvantages:
            Time to reprocess transactions may be prohibitive
              Processing of new transactions delayed until recovery
            Sequencing of transactions will often be different from
             when they were originally processed: may lead to
             different results.
              Original Run: customer deposit may be posted before
              Rerun: Withdrawal transaction may be attempted first.
        Last resort in database processing
Recovery and Restart Procedures
        DBMS backs out of or undo unwanted changes to the DB –
         before images captured
        Reverse the changes made by transactions that have aborted
         or terminated abnormally
        Example: transfer 100 from account for cust A to cust B
            Program reads the record for customer A and subtracts 100 from
             the acc balance
            Program reads the record for customer B and adds 100 to the acc
            Program writes the updated record for A to the dbase.
            In attempting to write the record for B, program encounters an
             error condition and cannot write the record.
            An UNDO command – recovery manager to apply the before
             image for record A to restore acc balance to its original value.

Recovery and Restart Procedures
Recovery and Restart Procedures   18
        A technique that starts with an earlier copy of
         the database. After images are applied to the
         database and the database is quickly moved
         forward to a later state.
        Much faster than Restore/Rerun:
        The time consuming logic of reprocessing each
         transaction does not have to be repeated
        Only the most recent after-images need to be
         applied. DB record may have series of after
         image – most recent (good) after image is
         required for rollback

Recovery and Restart Procedures
Recovery and Restart Procedures   20
        Integrity of transactions: DB is updated by
         processing transactions that results in changes
         to one or more DB records

        When processing transactions, DBMS must
         ensure that the transactions follow four well-
         accepted properties – ACID
          Atomic
          Consistent
          Isolated
          Durable

Recovery and Restart Procedures
        To maintain transaction integrity – DBMS must
         provide facilities for the user or application
         program to define transaction boundaries –
         logical beginning and end of transaction.

                                  BEGIN TRANSACTION

Recovery and Restart Procedures
   Aborted transactions
       Preferred recovery: rollback
       Alternative: Rollforward to state just prior to abort
   Incorrect data
       Preferred recovery: rollback
       Alternative 1: rerun transactions not including inaccurate
        data updates
       Alternative 2: compensating transactions
   System failure (database intact)
       Preferred recovery: switch to duplicate database
       Alternative 1: rollback
       Alternative 2: restart from checkpoint
   Database destruction
       Preferred recovery: switch to duplicate database
       Alternative 1: rollforward
       Alternative 2: reprocess transactions
   Contingency plans to cater for disasters –
    destroy/damage data center
   Natural disasters
   Planning for DR
   Develop a detailed DR plan
   Schedule regular test of plan
   Choose multi-disciplinary team to carry out
   Fast backup data center – off site location
   Send back up copies to backup data center
   Contingency plan is established to deal with unusual
    events that are not part of the normal daily routine
   Contingency plans detail the response necessary to
    deal with the types of event that may occur
   A contingency plan should include :
       who the key personnel are and how they can be contacted
       if the key personnel are unavailable, a list of alternative
        personnel and how they can be contacted
       who decides that a contingency exists and how that is decided
       the technical requirements of transferring operations elsewhere
       the operational requirements of transferring operations
       any outside contacts who may help
       whether any insurance exists to cover the situation

Shared By: