Chapter 15 Recovery

Topics in this Chapter Transactions Transaction Recovery System Recovery Media Recovery Two-Phase Commit SQL Facilities

Recovery Recovery means to restore the database to a correct state after some failure has rendered the current state incorrect or suspect Recovery is based on redundancy (!) To recover a database, the source for the recovery must be information that has been stored redundantly somewhere else Physical redundancy is desirable; logical redundancy is not

Recovery “Manually:” Make a backup copy of the database Make change 1, change 2, etc. If any problem arises, go back to the backup copy and start again Everything OK, discard the backup

Recovery A DBMS is expected to provide support DBMS can do it more efficiently DBMS can do it more safely User must play a role by defining transactions

Transactions A transaction is a logical unit of work It begins with BEGIN TRANSACTION It ends with COMMIT or ROLLBACK The transaction manager is sometimes known as the TP Monitor (transaction processing monitor) Atomicity: The manager guarantees that if any part of the transaction fails, the entire transaction will be rolled back, and the database set to its state before BEGIN

Transaction Manager COMMIT signifies transaction has completed successfully ROLLBACK signifies transaction has encountered an error Implicit ROLLBACK: if the transaction manager does not receive an explicit COMMIT, it will default to ROLLBACK After COMMIT or ROLLBACK, a message is returned to the user

Example Add a new employee with two dependents to the database Add employee to EMPLOYEES Add dependents to DEPENDENTS Must do it “atomically” since “partial” success produces inconsistency –Add dependent(s) without adding employee –Add one dependent, add employee with 1 dependents

Example // begin transaction try stmt.executeUpdate( ); stmt.executeUpdate(“COMMIT”); } catch (SQLException ex) stmt.executeUpdate(“ROLLBACK”); } // end transaction no explicit “begin transaction” required transaction ends with COMMIT or ROLLBACK

Transactions Atomicity of transaction is user’s responsibility Atomicity of statements is DBMS responsibility UPDATE EMPLOYEES SET SALARY = SALARY*1.1 WHERE DEPT# = ‘K43’ Can’t quit in the middle with DB partially updated

Transactions Changes are temporary (kept in buffers) until COMMIT or ROLLBACK COMMIT: makes temporary changes permanent ROLLBACK: discards the changes COMMIT or ROLLBACK will close an open CURSOR

Transactions The transaction is the “unit of recovery” When a transaction is committed, the changes are permanent even if the system subsequently crashes DBMS must provide for this

Recovery Log A recovery log or journal keeps the before and after state for each transaction An active (online) log is kept for immediate recovery of recent activity An archive log is kept offline for more extensive recovery requirements Atomicity must be at the statement level (set processing) Transactions must not be nested

Correctness The database must always be consistent, which is defined as not violating any known integrity constraint The DBMS can enforce consistency, but not correctness The DBMS must assume the correctness of transactions If the transaction is correct, and the prior state of the database was correct, then the resulting state of the database will be correct

COMMIT Point Database updates are kept in buffers, and written to disk after COMMIT The log must be written before COMMIT (“write- ahead” log rule) so the database can recover if the system crashes after COMMIT but before disk writing is complete On COMMIT (defaults to) all database positioning is lost and tuple locks released This is the COMMIT point, or synchpoint

Transaction Recovery ROLLBACK will return the database to the previous COMMIT point In large multiprocessing environments, transactions can “steal” buffer space from their predecessors, which can cause early disk writing Similarly, the DBMS can use a “no force” policy, meaning that writing to disk is held until additional transactions complete

The ACID Properties Atomicity – Transactions are atomic Correctness (f/k/a “Consistency”) – Transactions transform a correct state of the database into another correct state Isolation – Transactions are isolated from one another Durability – Once a transaction commits, its updates persist

Local Failures begin program begin transaction. commit end begin transaction. rollback end begin transaction. commit end etc. end program first transaction OK second transaction “cancelled” (local failure) third transaction OK user works from log of cancelled transactions to fix and/or reprocess

Global Failures System failure Power failure Memory failure Communication failure (soft crash) Media failure (hard crash)

Global Failures Suppose a memory failure--buffers lost, transactions in process lost transaction i i + 1. i + k i + k + 1. i + m i + m + 1 committed, written to disk in process, not committed committed, in disk buffers

System Recovery The system takes checkpoints automatically Upon system restart after a crash, transactions that finished successfully prior to the crash are redone, and those that were not complete prior to the crash are undone REDO and UNDO logs ARIES: Algorithms for Recovery and Isolation Exploiting Semantics – recovery by repeating history – REDO first, then UNDO

Fig 15.3 Five transaction categories

Fig 15.3 Five transaction categories At intervals (e.g., after n log entries) 1) Write all buffers 2) Write “checkpoint record” of all transactions in process 3) Continue to log all activity

Fig 15.3 Five transaction categories T1: transactions completed and written to disk before last checkpoint T2, T4: transactions completed but not written to disk at time of last check point T3, T5: transactions in process at time of failure Categories

Fig 15.3 Five transaction categories “OK” must be repeated--committed but not written to disk rollback (never completed)

Recovery System processes the checkpoint record to find all transactions appearing in last checkpoint and makes an UNDO list System searches (forward) through the log starting from the checkpoint and if a begin transaction is found add the transaction to UNDO list if a commit log entry is found for a transaction, move it from UNDO to REDO Then, when finished UNDO is a list of types 3 and 5 REDO is a list of types 2 and 4

Media Recovery Disk failure can corrupt the persistent database The database must be restored from backup The transaction logs can be used to roll forward from the backup point, to recover as much of the recent transaction history as possible

Two-Phase Commit Required for distributed or heterogeneous environments, so that correctness is maintained in case of failure during a multi-part COMMIT Prepare phase has all local resource managers force logs to a persistent log, local managers reply ok or not Commit phase – if all replies are ok, the coordinator commits, and orders the local managers to complete the process; otherwise all are ordered to ROLLBACK

Two-Phase Commit Database X: DB2 Database Y: Oracle transaction fragment at node B fragment at node C transaction at node A or each DBMS maintains its own recovery log

Two-Phase Commit Transaction completes, issues COMMIT (system wide) Phase I : System coordinator process tells each participant to “get ready” i.e., each log is written to disk, therefore each participant can go “either way” If coordinator gets OK from all participants, it writes a physical record to its log saying COMMIT Othewise, coordinator writes physical record saying ROLLBACK

Two-Phase Commit Phase II : Notifies participants to do whichever it decided (they must) If there is a failure during Phase II, system can find the decision record If failure during Phase I, or it can’t find the decision record, it becomes a ROLLBACK

SQL Facilities START TRANSACTION ; The option commalist specifies an access mode, an isolation level, or both Access mode can be READ ONLY or READ WRITE Isolation level sets isolation from other transactions SAVEPOINT establishes a point within a transaction to which you can ROLLBACK