9_Transaction Processing Recovery

7/27/2019 9_Transaction Processing Recovery

http://slidepdf.com/reader/full/9transaction-processing-recovery 1/27

n tTransaction Processing: Recovery

© 2010 Zvi M. Kedem 1

Transaction Processing

Implemented as part of the Database Operating System

• Recovery (this unit)

• Concurrency (next unit) Relies on services provided by the “standard” operating

system running on the hardware

View View

Community

Database Operating System


Example: Money Transfer

Transfer $50 from account a to b (items on the disk)

1. transaction starts2. read a into xa (local variable in RAM)3. xa := xa − 50

4. write xa onto a5. read b into xb (local variable in RAM)6. xb := xb + 507. write xb onto b8. transaction ends

If initial values are a = 180 and b = 100


Example: Money Transfer

Sample values of database variables at various points in acompleted execution

a b180 100

1. transaction starts 180 1002. read a into xa 180 1003. xa := xa − 50 180 1004. write xa onto a 130 1005. read b into xb 130 1006. xb := xb + 50 130 1007. write xb onto b 130 1508. transaction ends 130 150




The Fate Of A Transaction

Start Transaction

Commit Transaction Abort Transaction

(Will Exist Forever)

(Never Existed)


History (Schedule)

This is a trace of execution of transactions in a system• This is somewhat imprecise at this point

• We will make it more formal as needed

Example at the beginning of the unit was a trace At different time we will “trace” different actions

• Most commonly which transaction accessed which item in whichmode

• E.g. T1 R x; meaning transaction T1 Reads item x


Recoverable Histories

A history is recoverable if for every transaction T thatcommits, the Commit of T follows the Commit of everytransaction from which T read• We do not formally define here what it means “from which T read,”

but it is pretty obvious intuitively: T read the result of writing by that

transaction Histories must be recoverable, otherwise transaction

ma o erate based on non-existent ast

A history that is not recoverable

W x

W yCommit


Recoverable Histories

Here is what could happen next

T1 T2

W x

R xW yCommit

Abort

n now w a o o a ou• It operated using a non-existent value of x (here y could have

been x + 1)

• It cannot be aborted because it has already committed




More On Recoverable Histor ies

We need to understand what is wrong with the following

T1 T2

W xR xCommit

It may seem that there is no problem because T2 onlyread

Consider the following case:•

Initially x = 0 and y = 0=

• T2 is: if x = 0 then y := 1

Then the value of x did matter and depending on whether


T1 existed or not the behavior of T2 is different

Cascading Aborts

A history avoids cascading aborts if every transactionreads only values produced by transactions that havealready committed

Of course it can read the initial state unless overwritten

• We will assume, to simplify discussion, some transaction T0,running by itself and creating the initial state of the database

s recovera e, au oma ca y

A history that does not avoid cascading aborts

T1 T2

W xR xW y


Cascading Aborts


T1 T2

W x

R xW y Abort

Then we must do:

T1 T2

x R xW y


Abort Abort

Strict Histories

History is strict if • Satisfies the condition for avoiding cascading aborts

• For every transaction, if it writes an item, all the transactions thatpreviously wrote that item have already committed or aborted

,

most convenient thing to implement is just to restore thevalue that existed previously

a s ory s no s r c , s s no goo enoug

A histor that is not strict

T1 T2

W xW x




Strict Histories


T1 T2

WxWx

Abort

Even though T1 aborted, we must not do anything to x!


Strict Histories

Here what could happen next

T1 T2

WxWx

Abort Abort

Because T2 aborted, we must restore the value of x thatex s e e ore wro e

Ver com licated; need to maintain several values for x


Relations

Strict implies no cascading aborts

No cascadin aborts im lies recoverable

So we like strict, which really means:

• Every transaction reads only values produced by transactions thathave already committed

• Every transaction, if it writes an item, all the transactions thatpreviously wrote that item have already committed or aborted

But note: a transaction can read a value that was read by

We will assume that the DB OS will make sure that allhistories will be strict

This will be automatically ensured by concurrencymanagement (next unit)


Reminder On Virtual Memory: Paging In And Out

Disk RAM

a b c d

Access a a b c d a

Access b a b c d ba

ccess c a c c

“Access” means read or write


4 blocks on the disk and 2 page slots in the RAM cache



Addi tional Assumpt ions On Execut ion

The log always runs ahead of the execution in RAM(not strictly necessary, but convenient to assume)

So if xold is replaced by xnew in RAM, then in order

1. The log record “T x xold xnew” is written in the log buffer (in RAM). new

On the log, values are written in the same sequentialorder in which the write instructions are issued because itis a sequential file

,latest value• It obtains it from the virtual memory pool or if not there, from the


Addi tional Assumpt ions On Execution

The log always runs ahead of the execution on theDisk

So if xold is replaced by xnew, then in order

1. The log record “T x xold xnew” is actually written in (actuallyfailure before this is done

2. xnew is actually written on the disk (but this may actually never ha en even if there are no failures, we will see wh later

On the log, values are actually written in the samesequential order in which the write instructions are issued


Temporal Ordering Constraints On Execution


“ Tracing” Two Writes And Their Tem oral Order in Constraints

Originally, x = 10 and y = 20

In the execution: 1. x := 11

2. y := 21

Eight actionsa. x := 11 in RAM

b. := 21 in RAM

c. x := 11 on Disk

d. y := 21 on Disk

.

f. T y 20 21 in RAM

g. T x 10 11 on Disk

h. T y 20 21 on Disk




Two Transactions (Programs)

Transactions T1 and T2

= = = = = =, , , , ,70

The instructions labeled with roman numerals are really

perhaps on the Disk)

Note “perhaps” above

T1 T2

read a read eread(b);

i: b := a + b;

iv: e := e − 10;

read(a);= +ii: c := 2c;iii: a := a + b + c + 50;

read(d);read(b);

= +


A History Of An Execut ion In RAM

T1 T2

read(b); //300

i: b := a + b; //400

read(c); //5ii: c := 2c; //10

= −

iii: a := a + b + c + 50; //560

read(a); //560 read(d); //80

read(b); //400


Write Instructions For The History

Log records

1. T1 starts2. T1 b 300 4003. T2 starts

.

5. T2 e 60 506. T1 a 100 5607. T1 commits8. T2 a 560 5709. T2 d 80 48010. T2 commits

Database items

(ii) c 10(iv) e 50iii a 560


(v) a 570(vi) d 480

Temporal Constraints

There are certain temporal constraints, which we indicateby “<“

If action1 < action2, where the actions are actualwrites, this means that necessarily, in any execution,

action1 has to come before action2

1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 < 9 < 10• Because actual write to a sequential file (the log), are processed in

“ - ”-

2 < i, 4 < ii, 5 < iii, 6 < iv, 8 < v, 9 < vi• Because actual writing to the log is ahead of actual writing to the

a a ase




Temporal Constraints

iii < v• Because an “older” value of a could not have existed in RAM after

a “newer” value was produced, therefore

• If v is actually written, it has been in RAM (for some time) and iii is

not longer in RAM. Note however that iii need not have taken place!

• Because, the disk is only “sometimes” updated (when there is noroom in virtual memor or ma be when we “force” u date of the blocks on the disk)


A Possib le Order of Act ions

The order of actual writes might be:

log database

1

34

iii

5678

9vviv

10


Possible Situation After “ write d” Was Issued

Disk RAM

og

a = 570b = 400

9. T2 d 80 480

og

a = 100b = 400

1. T1 starts2. T1 b 300 400

d = 80e = 60f = 70

.

4. T1 c 5 105. T2 e 60 506. T1 a 100 5607. T1 commits8. T2 a 560 570

c ua wr es processe n or er: , , , , , , , , ,

Notes concerning “write d”:• It has alread been reflected in the lo in RAM

• It has not yet been reflected in the DB in RAM

• It has not yet been reflected in the log on Disk


• as no ye een re ec e n e on s

Example

Originally DB on the disk: a=100, b=300, c=5, d=80, e=60, f=70

, .the new values are indicated, as they are written there

Line Log/RAM DB/RAM (4 slots) Log/DiskDB Disk

1 2 3 4

1 T1 Starts

2 a=100

3 b=300

4 T1 b 300 400

5 b=400

6 T2 Starts

7 e=60

8 T1 Starts

9 c=5

10 T1 B 300 400

11 T2 Starts




Example

13 c=10

14 T2 e 60 50

e=

16 T1 c 5 10

17 T1 a 100 560

18 a=560

19 T1 Commits

20 T2 a 560 570

21 a=570

22 c=10

23 d=80

24 T2 d 80 480

=

26 T2 e 60 50

27 T1 a 100 560

28 T1 Commits

29 T2 a 560 570

30 T2 d 80 480

31 e=50


32 d=480

33 a=570

Example

34 T2 Commits

35 T2 Commits


Example

Easy to see (next slides with some examples) thattemporal constraints we required are satisfied


Example

Examples of constraints:• Log in RAM ahead of changes in DB in RAM: 4 before 5

• Log in RAM ahead of Log on Disk: 4 before 10

• DB in RAM ahead DB on Disk: 5 before 25

Note that value of a = 560 in DB in RAM was never writtento the DB on Disk

It is necessary to write value from DB in RAM to DB in

But also good to do when the system shuts down (thoughstrictly not required

• Because the system can shut down by crashing and of course it isthen too late to write values from DB in RAM to DB in disk




Recovery Procedure

Start scanning the log you see on the disk backwardsfrom the end to the beginnig, producing two, initiallyempty, lists (sets)• Undo list

• Redo list

For every transaction for which you have a commit record,add it to the redo list

For each transaction for which you have a start record butnot a commit record, add it to the undo list

1. Undo all actions of transactions in the undo list by going

backwards from end to beginning, by copying old valuesf rom Lo to DB

2. Redo all actions of transactions in the redo list by goingforward from beginning to end, by copying new values fromDB to Log


Examining Al l Cases For Log On Disk

Log consists of the sequenceT1 StartsT1 b 300 400T2 Starts

T1 c 5 10 T1 a 100 560T1 CommitsT2 a 560 570T2 d 80 480T2 Commits

Redo T1; Redo T2. Write in DB on Disk:b = 400c =10

e = 50a = 560a = 570d = 480


o re ec e ; o re ec e


Log consists of the sequenceT1 StartsT1 b 300 400T2 StartsT1 c 5 10

T1 a 100 560T1 CommitsT2 a 560 570T2 d 80 480

Undo T2; Redo T1. Write in DB on Disk:b = 400d = 80a = 560

e =c = 10a = 560


o re ec e ; one o re ec e



T1 a 100 560T1 CommitsT2 a 560 570

Undo T2; Redo T1. Write in DB on Disk:b = 400a = 560e = 60

c =a = 560







T1 c 5 10 T1 a 100 560T1 Commits

Undo T2; Redo T1. Write in DB on Disk:b = 400e = 60

c = 10a = 560





T1 c 5 10 T1 a 100 560

Undo T2; Undo T1. Write in DB on Disk:a = 100e = 60

c = 5b = 300

None of T1 reflected; None of T2 reflected




T1 a 100 560

Undo T2; Undo T1. Write in DB on Disk:a = 100e = 60c = 5

=





Undo T2; Undo T1. Write in DB on Disk:e = 60c = 5b = 300







T1 c 5 10

Undo T2; Undo T1. Write in DB on Disk:c = 5b = 300





Undo T2; Undo T1. Write in DB on Disk:b = 300




Log consists of the sequenceT1 StartsT1 b 300 400

Undo T1. Write in DB on Disk:b = 300




Log consists of the sequenceT1 Starts

Undo T1. Write in DB on Disk:





SQL Support

DDL statements issue an implicit COMMIT after their execution

This implies that change to data is committed too

We do not discuss this further here

can e a e o save par a wor

This may be useful for implementing subtransactions(smaller units of consistency)


Advanced Mater ial


Checkpointing

A technique to obviate the need to look at the completelog and thus reduce the work during recovery

During the execution in addition to the activities of theprevious algorithm, periodically perform checkpointing in

1. Stop processing (suspend transactions)2. Force log buffers on Disk log (“force” means “actually write”)

3. Force database buffers on Disk database

4. Write on the log the list of transaction currently running (currentlysuspended)

5. Write CHECKPOINT DONE on the log

6. Resume processing

Check ointin in fact s nchronizes the database with the

log• The database reflects everything actually written in the log by this


Checkpointing

We will simplify and assume that we can write in oneblock a checkpoint record that both list the transactionsand that checkpointing was done

So we combine steps 4 and 5

ur ng e execu on n a on o e ac v es o e

previous algorithm, periodically perform checkpointing inthis precise order:1. Stop processing

2. Force log buffers on Disk log (“force” means “actually write”)

3. Force database buffers on Disk database

4. Write and force “checkpoint record” on log

• List of transactions running at this time

5. Resume processing




E l L O Th Di k Af t A C h P ti R O Thi L



Example Log On The Disk Af ter A Crash

T1 starts

T1 a 0 10

T1 commits

T2 starts

T2 b 0 10T3 starts

T3 c 0 10

T3 c 10 20

checkpoint T2 T3

T4 starts

T2 a 10 20

T4 d 0 10

T5 starts

T6 startsT6 e 0 10

T6 aborts (needs discussing we will ignore it here)

T2 commits


T5 a 20 500

T4 commits

Practice Recovery On This Log

We ignore (for simplicity of discussion): transaction T6and item e

Possible values on the disk after crash:• a = 10 or 20 or 500

• =

• c = 20

• d = 0 or 10

Undo list: T5, T3

Redo list: T4, T2

Actual writes• a := 20

• c := 10

• c := 0

• a := 20


•

Practice Recovery On This Log

Final values• a = 20

• b = 10

• c = 0

Transactions existed (reflected): T1, T2, T4

Transaction not existed not reflected : T3, T5


Big Recovery Example

I ni t i al val ues: a = b = c = d = e = f = g = h = i = j = k = 0

On the l og af t er t he crash:

T1 a, 0, 1

T2 STARTS

T2 b, 0, 1

T3 STARTS

T3 c, 0, 1

T4 STARTS

T4 d, 0, 1

T4 e, 0, 1

T4 COMMI TS

T5 f , 0, 1

T6 STARTS

T6 g, 0, 1

T2 d, 1, 2CHECKPOI NT T1, T2, T3, T5, T6

T2 h, 0, 1


T2 COMMI TS

T5 h, 1, 2



Refining The Model Scenario



Refining The Model

Records of the log are likely to be small compared to thesize of the block/page• So many of them fit in a block


Scenario

We will consider a stream of frequent transactions, eachof them modifying one tuple of a relation, that is onerecord of the file storing the relation

These transactions are submitted by interactive users

So, the transactions have to be acknowledged assuccessful relatively quickly

So, the transactions have to be committed relativelyquickly


Without Recovery

Each transaction modified only one record

But a block of the database containin this record must be written before commit

So, to commit a transaction a block must be written


With Recovery

Each transaction modified one record

But a block of the lo containin information about the record (transaction_name, record_identifier, old_value,new_value) must be written before commit

o, o comm a ransac on s oc mus e wr en

But this block contains information for manytransactions

So a single block write commits many transactions

So the overhead of recovery may result in much moree c en execu on


Example

Initial State Of The Memory Pool



Example

We will consider a simple example

, ,

The database is a vector of 72 integers

A block contains 18 records, each of one integer There is room in the RAM for 5 blocks

The whole database can be kept in RAM for processing,“ ”u w en a ransac on comm s, some ng mus e

written to the disk

There will be 6 transactions


Initial State Of The Memory Pool

The vector needs 4blocks, of 18integers in the RAMvirtual memory pool


Without Recovery Mechanism

We need to write one block to commit each transaction


Initial State Of Memory Pool

Initial database inRAM


Af ter Transact ion 1 After Transact ion 2



Af ter Transact ion 1

We need the newvalues to be instable storagebefore commit

position 1, block 1needs to be written

before commit canbe done and

















Af ter Transact ion 5 After Transact ion 6













With Recovery Mechanism

We do not need to write one block to commit eachtransaction

We write one full log block to commit “many” transactions


Initial State Of Memory Pool

Empty log blockand initial databasein RAM


Af ter Transact ion 1 Af ter Transact ion 2




position 1, log blockdescribing this

written out to thedatabase before

done and reportedto the user

ransac onscome frequently,we can wait until


log block is full


position 21, logblock describing

to be written out tothe database

be done andreported to the user



log block is full








log block is full







© 2010 Zvi M. Kedem 100

log block is full

Af ter Transact ion 5 Af ter Transact ion 6








© 2010 Zvi M. Kedem 101

log block is full






© 2010 Zvi M. Kedem 102

log block is full

Committing The Transactions

The block of the log is written out, committing thetransactions

Nothing is done to the four blocks of the database residingin RAM (at least for a while)

© 2010 Zvi M. Kedem 103

New State Of Memory Pool

Ready for newtransactions

© 2010 Zvi M. Kedem 104

Conclusion Key Ideas



Running with recovery resulted in significant reduction of block writes

In addition, of course, to supporting recovery well

© 2010 Zvi M. Kedem 105

Need for recovery support in DB OS

• Atomic

• Consistent

• s o a e

• Durable

Stora e model• Disk: stable storage

• RAM: volatile storage

ransac on en s w one o e wo ac ons• Commit

• Abort

History (Schedule)

© 2010 Zvi M. Kedem 106

Key Ideas

Some types of histories:• Recoverable

• Avoids cascading aborts

• Strict

ecovery suppor us ng wr e a ea ogs

Problems with interactive transactions

Checkpointing

Refining the model

© 2010 Zvi M. Kedem 107

9_Transaction Processing Recovery

Documents

Transcript of 9_Transaction Processing Recovery