database management

Chapter 15 Recovery

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-2

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-3

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-4

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-5

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-6

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-7

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-8

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.

15-9

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.

15-10

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.

15-11

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.

15-12

Two-Phase Commit

• Required for distributed or heterogeneous environments, so that correctness is maintained in case of failure during a multipart 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.

15-13

SQL Facilities

• START TRANSACTION < option commalist > ; • 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 Copyright © 2004 Pearson Addison-Wesley. All rights reserved.

15-14