Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Topics Overview Recovery (System vs. Media & Backward vs. Forward) Transaction Transaction Management ACID property for transactions Transaction recovery SQL support

Recovery Recovery in database system means recovering the database itself, i.e., restoring the database to a state that is known to be correct after some failure has rendered the correct state incorrect, or at least suspect Relationship with redundancy:: To make sure that the database is indeed recoverable is to make sure that any piece of information it contains can be reconstructed from some other information stored, redundantly some where else in the system

Single-User vs. Multi-User Single-User System: At any given time, at most one user can use the system Multi-User System: Many users can access the system concurrently Concurrency: ◦ Interleaved Processing: concurrent execution of processes is interleaved in a single CPU ◦ Parallel Processing: Processes are concurrently executed in multiple CPUs

Transaction A Transaction: logical unit of database processing that includes one or more access operations (read – retrieval, write – insert/update, delete) A Transaction (Set of operations) may be stand-alone specified in a high-level language like SQL submitted interactively, or may be embedded in the program Transaction Boundaries: Begin and End transaction An application program may contain several transactions separated by Begin and End transaction boundaries

Transaction Recovery Recovering the database after some individual transaction has failed for some reason System Recovery: Recovering after some kind of system crash has caused all the currently running transactions to fail simultaneously Media Recovery: Recovering after the database has been physically damaged in some way, e.g., by head crash on disk

Backward vs. Forward Recovery Restoring the database to a correct state by undoing work is sometimes called backward recovery Restoring the database to a correct state by redoing work is sometimes called forward recovery

Transaction Management Transaction management is a task of supervising the execution of transactions in such a way that they can indeed be guaranteed to possess some of the important properties called ACID properties ◦ Atomicity ◦ Consistency ◦ Isolation ◦ Durability

ACID Properties Atomicity: A transaction is an atomic unit of processing; it is either performed in its entirety or not performed at all. (All or Nothing) Consistency Preservation: Transformations preserves database consistency. A correct execution of the transaction must take the database from one consistent state to another consistent state, without necessarily preserving consistency at all intermediate points

ACID Properties (…Cont) Isolation: Transactions are isolated from one another. A transaction should not make its update visible to other transactions until it is committed; this property, when enforced strictly, solves the temporary update problem and makes cascading rollbacks of transactions unnecessary Durability (Or Permanency): Once a transaction changes the database and the changes are committed, its update survive, i.e., these changes must never be lost because of subsequent failures (System Crash)

Transaction Manager The system component that provides the atomicity is known as “transaction manager” and the operations “Commit” and “Rollback” are the key to the way it works. Transactions are initiated by BEGIN TRANSACTION and terminated either by Commit or Rollback Commit establishes a commit point (updates are made permanent) while Rollback rolls the database back to the previous commit point (updates are undone)

COMMIT & ROLLBACK COMMIT TRANSACTION: It signals successful end of transaction; it tells the transaction manager (TM) that a logical unit of work has been successfully completed, the database is in consistent state again, and all of the updates made by the unit of work can now be committed or made permanent ROLLBACK TRANSACTION: It signals unsuccessful end of transaction; it tells the TM that something has gone wrong, the database might be in an inconsistent state, and all of the updates made by the logical unit of work so far must be rollback or undone

Recovery Log If a transaction does not reach its planned termination, the system will force a ROLLBACK for it (transaction recovery). In order to be able to undo updates, the system maintains a recovery log The log records for a given transaction must be written to a physical log before COMMIT processing for that transaction can complete: this is a write-ahead log rule

REDO & UNDO Operations The system also guarantees the ACID properties of the transaction in the case of a system crash. To provide such guarantee, the system must: ◦ REDO all the work done by transaction that completed successfully prior to the crash ◦ UNDO all the work done by the transaction that started but didn’t complete prior to crash

System Recovery The system recovery activity is carried out as part of the system’s restart procedure (sometimes known as the restart/recovery procedure) The system discovers what work has to be re-done and what undone by examining the most recent check point record Check point records are written to the log at prescribed intervals