Hiram CPSC 356 - Recovery CPSC 356

Unformatted text preview:

RecoverySlide 2Types of FailureDatabase InconsistenciesTransactions and RecoveryWrite operation (change a salary)Buffer vs. Secondary StorageExample Transactions & FailureManaging BufferManaging Buffer (continued)Facilities needed for recoveryBackupLog FileSample Log FileKeeping Log File SafeCheckpointsRecovery TechniquesDeferred UpdateConsequences of Deferred UpdateImmediate UpdateConsequences of Immediate UpdateRecoveryCPSC 356 DatabaseEllen WalkerHiram College(Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)Recovery•Ensure that the database is reliable and consistent in the presence of failure•Recovery methods depend on failure typesTypes of Failure•System crash -> loss of main memory•Media failure -> loss of (part of) secondary storage•Application software error -> failed transaction•Natural physical disaster•Carelessness•SabotageDatabase Inconsistencies•Incomplete (not committed) transaction has changed database on disk•Committed transaction’s data not completely written to disk•Transaction changed the database, then abortedTransactions and Recovery•Recall ACID–Atomicity = all or nothing–Durability = once done, not undone•A transaction, once permanently recorded in memory, cannot be undone (or partially undone) due to failure•Problem: writing to secondary storage is interruptibleWrite operation (change a salary)•Find the address of the disk block that contains the record with the desired primary key•Transfer the disk block into a database buffer in main memory•Copy the salary from a variable (register) into the database buffer•Write the database buffer back to disk (FLUSH)Buffer vs. Secondary Storage•Write buffer to secondary storage–When buffer becomes full–When an explicit flush command is given•If failure occurs when data is in buffer–If transaction is committed, flush the buffer (REDO)–If transaction is not committed, undo any effects that already made it to disk (UNDO)Example Transactions & Failure•Checkpoint (buffers flushed) at tc, failure at tf•Transactions 4 and 5 should be redone, 1 and 6 should be undoneManaging Buffer•Dirty bit – set when the buffer has been changed (i.e. buffer ≠ secondary storage)•Pin count–Initialize to 0–Increment when buffer is requested–Decrement when system indicates buffer is not needed anymore (e.g. transaction commits)–If pin count is 0, buffer is available for replacement (write back if dirty)Managing Buffer (continued)•Steal Policy–Buffer can be written to disk before transaction commits•Force Policy–Buffer must be written to disk when transaction commits•Simplest = no steal, force•Most common = steal, no-force–Reduce buffer size; reuse page info in memoryFacilities needed for recovery•Backup mechanism–Periodic backups of entire database (time-stamped) + log file•Logging facilities–Track transactions & database changes•Checkpoint facility–Force updates in progress to become permanent•Recovery manager–Restores system to consistent state after failureBackup•Recovery from catastrophic failure = choose the latest consistent backup•Backups generally kept on non-volatile media, offsite•Can be complete or incrementalLog File•Information about transactions used to undo/redo changes•Transaction records:–Id, type (start, insert, update, delete, abort, commit)–Item(s) affected•Before value(s) + after value(s)•Checkpoint records (later)Sample Log FileKeeping Log File Safe•Maintain multiple (2 or 3) separate copies of file•At least 1 backup copy on online fast direct-access storage device (e.g. additional mounted hard-drive) for fast recoveryCheckpoints•Points of synchronization between database and log file (all in secondary storage)•At each checkpoint–Write all log records in main memory to secondary storage–Write modified blocks in database to secondary storage–Write a checkpoint record to the log file (all active transactions identified)•Recovery needed only back to last checkpointRecovery Techniques•After extensive damage (e.g. head crash)–Restore last backup copy–Reapply committed transactions using log (if log is still available)•In case of limited inconsistency–Undo transactions that caused inconsistency–Redo transactions as needed –“Deferred update” or “immediate update”Deferred Update•Write ‘transaction start’ record to log•Update log (but not DB) for each write operation•Write ‘transaction commit’ record to log•Write log to disk•Perform writes to DB according to logConsequences of Deferred Update•Aborted transaction–No effort needed; just ignore log’s write entries•Database failure–Start at most recent checkpoint–Log is already available on disk; redo write operations according to log–Transactions with both start & commit in log are redone–Writes redone in order written to logImmediate Update•Write transaction start record to log•For each write operation, write the record to the log first, then perform the write to the DB buffers•Write to disk when DB buffers are flushed•When transaction commits, write commit record to logConsequences of Immediate Update•Log always updated before DB (write-ahead log protocol)•If transaction aborts, use log information to undo it•In case of failure, any transaction without commit record in log needs to be undone•If there are both transaction start and transaction commit records for a transaction, that transaction needs to be


View Full Document

Hiram CPSC 356 - Recovery CPSC 356

Download Recovery CPSC 356
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Recovery CPSC 356 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Recovery CPSC 356 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?