1

ICS 214A: Database Management Systems Fall 2002

Lecture 16: Crash RecoveryProfessor Chen Li

ICS214A Notes 16 2

Integrity or correctness of data

• We would like data to be “accurate” or “correct” at all times

EMPName

TomJackMary

Age

5234211

ICS214A Notes 16 3

Integrity or consistency constraints

• Predicates data must satisfy• Examples:

- x is key of relation R- x y holds in R- Domain(x) = {Red, Blue, Green}is valid index for attribute x of R- no employee should make more than twice

the average salary

• SQL uses “constraints” or “triggers” to enforce integrity– “CHECK age > 16 AND age <= 99”

ICS214A Notes 16 4

Definitions

• Consistent state: satisfies all constraints

• Consistent DB: DB in consistent state

• Ideally: database should reflect real world

DBReality

ICS214A Notes 16 5

A1

A2

.

.

500

.

.

500

.

.

600

.

.

500

.

.

600

.

.

600

Example: Salary A1 = Salary A2 (constraint)

Deposit $100 in A1: A1 A1 + 100

Deposit $100 in A2: A2 A2 + 100

DB may not be always consistent!

ICS214A Notes 16 6

Transaction: collection of actions that preserve consistency

Consistent DB Consistent DB’T

ICS214A Notes 16 7

Big assumption:

If T starts with consistent state + T executes in isolation

T leaves consistent state

Correctness (informally)

• If we stop running transactions, DB left consistent

• Each transaction sees a consistent DB

ICS214A Notes 16 8

How can constraints be violated?

• Transaction bug• DBMS bug• Hardware failure

e.g., disk crash alters balance of account

• Data sharinge.g.: T1: give 10% raise to programmers

T2: change programmers systems analysts

ICS214A Notes 16 9

How can we prevent/fix violations?

• Chapter 8 (17): due to system failures only• Chapter 9 (18): due to data sharing only• Chapter 10 (19): due to failures and sharing

• Customers don’t want to lose their data!– Think about 9/11!

Here we focus on “system failures”

ICS214A Notes 16 10

Coping with system failures

• Question 1: What is our Failure Model?

Events Desired

Undesired Expected

UnexpectedCPU

Memory Disk

ICS214A Notes 16 11

Desired events: see product manuals…

Undesired expected events:

System crash

- memory lost

- cpu halts, resets

ICS214A Notes 16 12

Examples:• Disk data is lost• Memory lost without CPU halt• CPU dies…

Undesired Unexpected: Everything else!

ICS214A Notes 16 13

Is this model reasonable?

Approach: Add low level checks + redundancy

E.g., Replicate disk storage (stable store)

Memory parity CPU checks

ICS214A Notes 16 14

Question 2

Storage hierarchy

Memory Disk

x x

ICS214A Notes 16 15

Operations:• Input (x): block with x memory

• Output (x): block with x disk

• Read (x,t): do input(x) if necessary t value of x in block

• Write (x,t): do input(x) if necessary value of x in block t

Memory Disk

x xt

ICS214A Notes 16 16

Key problem: Unfinished transaction

Example Constraint: A=B T1: A A 2 B B 2

ICS214A Notes 16 17

T1: Read (A,t); t t2Write (A,t);Read (B,t); t t2Write (B,t);Output (A);Output (B);

A: 8B: 8

A: 8B: 8

memory disk

1616

16

failure!

ICS214A Notes 16 18

• Need atomicity: execute all actions of a transaction or none at all

ICS214A Notes 16 19

• A log is a sequence of log records• Each record tells something about

what some transaction has done• Possible log records:

– <T Start>– <T COMMIT> – <T ABORT>– Update record: <T, X, v>

• Managed by the “Log Manager”

Log

ICS214A Notes 16 20

Topics• Undo logging• Redo logging• Undo/redo logging, why both?• Checkpoints• …

ICS214A Notes 16 21

T1: Read (A,t); t t2 A=B

Write (A,t);Read (B,t); t t2Write (B,t);Output (A);Output (B);

A:8B:8

A:8B:8

memory disk log

Undo logging (Immediate modification)

1616

<T1, start><T1, A, 8>

<T1, commit>16 <T1, B, 8>

16

ICS214A Notes 16 22

Undo logging rules1. For every action, generate undo

log record (containing old value).2. Before x is modified on disk, log

records pertaining to x must be on disk (write ahead logging: WAL).

3. Only after all writes of transaction must be reflected on disk can the “commit” record is flushed to log.

ICS214A Notes 16 23

Log in memory• Log is first written in memory• Not written to disk on every action

memory

DB

Log

A: 8 16B: 8 16Log:<T1,start><T1, A, 8><T1, B, 8>

A: 8B: 8

16BAD STATE

# 1

ICS214A Notes 16 24

Log in memory• Log is first written in memory• Not written to disk on every action

memory

DB

Log

A: 8 16B: 8 16Log:<T1,start><T1, A, 8><T1, B, 8><T1, commit>

A: 8B: 8

16BAD STATE

# 2

<T1, B, 8><T1, commit>

...

ICS214A Notes 16 25

Solution• The transaction needs

to call “FLUSH LOG” explicitly to force the log in memory to be flushed to disk

• Notice: even without calling “flush log”, some log records may have already been on disk!

T1:Read (A,t); t t2

Write (A,t);Read (B,t); t t2Write (B,t);FLUSH LOG;

(A and B log records

flushed to disk)Output (A);Output (B);

FLUSH LOG;(“COMMIT” record flushed to disk)

ICS214A Notes 16 26

Recovery rules: Undo logging• For every Ti with <Ti, start> in log:

- If <Ti,commit> or <Ti,abort> in log, do nothing

- Else For all <Ti, X, v> in log:write (X, v)output (X )

Write <Ti, abort> to log

IS THIS CORRECT?? NO!

ICS214A Notes 16 27

Recovery rules: Undo logging

(1) Let S = set of transactions with<Ti, start> in log, but no<Ti, commit> (or <Ti, abort>) record

in log(2) For each <Ti, X, v> in log,

in reverse order (latest earliest) do:

- if Ti S then - write (X, v)

- output (X)

(3) For each Ti S do

- write <Ti, abort> to log

ICS214A Notes 16 28

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);Flush log;Output (A);Output (B); Flush Log;

A:8B:8

disk log

Example 1

<T1, start>

failure!

Recovery: write <T1, Abort>

<T1, abort>

ICS214A Notes 16 29

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);Flush log;Output (A);Output (B); Flush Log;

A:16B:8

disk log

Example 2

<T1, start><T1, A, 8><T1, B, 8>

failure!

ICS214A Notes 16 30

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);Flush log;Output (A);Output (B); Flush Log;

A:16B:8

disk log

Example 2 (cont)

<T1, start><T1, A, 8>

8 <T1, B, 8>

8 <T1, abort>

failure!

ICS214A Notes 16 31

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);Flush log;Output (A);Output (B); Flush Log;

A:16B:16

disk log

Example 3

<T1, start><T1, A, 8><T1, B, 8>

failure!

Recovery same as Example 2

ICS214A Notes 16 32

What if failure during undo recovery?No problem! Since UNDO is idempotent, i.e., applying “UNDO” many times yields the same result as applying “UNDO” once.

ICS214A Notes 16 33

Redo logging (deferred modification)

T1: Read(A,t); t t2; write (A,t); Read(B,t); t t2; write (B,t);

Output(A); Output(B)

A: 8B: 8

A: 8B: 8

memory DB LOG

1616

<T1, start><T1, A, 16><T1, B, 16>

<T1, commit>

output16

ICS214A Notes 16 34

Redo logging rules1. For every action, generate redo

log record (containing new value)2. Before X is modified on disk (DB),

all log records for transaction that modified X (including commit) must be on disk

ICS214A Notes 16 35

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);FLUSH LOG;Output (A);Output (B);

A:8B:8

disk log

<T1, start><T1, A, 16><T1, B, 16>

Flush log before modifying DB elements

<T1, commit>

ICS214A Notes 16 36

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);FLUSH LOG;Output (A);Output (B);

A:8B:8

disk log

<T1, start><T1, A, 16>

failure!

Transactions without “COMMIT” log record

Remember: log records could be on disk before “flush log” is called.

ICS214A Notes 16 37

• For every Ti with <Ti, commit> in log:– For all <Ti, X, v> in log:

Write(X, v)Output(X)

Recovery rules: Redo logging

IS THIS CORRECT? NO!

ICS214A Notes 16 38

(1) Let S = set of transactions with<Ti, commit> in log

(2) For each <Ti, X, v> in log, in forward order (earliest latest) do: if Ti S then Write(X, v), Output(X)

(3) For each incomplete transaction Ti, write <Ti, Abort> record to the log.

Recovery rules: Redo logging

ICS214A Notes 16 39

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);FLUSH LOG;Output (A);Output (B);

A:8B:8

disk log

<T1, start><T1, A, 16>

failure!

Recovery: Example 1

Recovery: write an “abort” record

<T1, abort>

ICS214A Notes 16 40

T1: Read (A,t); t t2 A=BWrite (A,t);Read (B,t); t t2Write (B,t);FLUSH LOG;Output (A);Output (B);

A:8B:8

disk log

<T1, start><T1, A, 16><T1, B, 16>

Recovery: Example 2

<T1, commit>

failure!

1616