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(<insert employee>);

stmt.executeUpdate(<insert employee>);

stmt.executeUpdate(<insert employee>);

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 EMPLOYEESSET 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 programbegin transaction

. .commit

endbegin transaction

. .rollback

endbegin transaction

. .commit

endetc.

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 listSystem searches (forward) through the log starting from the checkpoint and

if a begin transaction is found add the transaction to UNDO listif 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 5REDO 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 COMMITOthewise, 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 < option commalist > ;

• 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