Chapter 15 Recovery

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-2 Topics in this Chapter Transactions Transaction Recovery System Recovery Media Recovery Two-Phase Commit SQL Facilities

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-3 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-4 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-5 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-6 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-7 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-8 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-9 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved 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

Copyright © 2004 Pearson Addison-Wesley. All rights reserved SQL Facilities START TRANSACTION ; The option commalist specifies an access point, 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