NEED


To provide atomicity

To ensure durability

Provides DB recovery technique in case of
power loss or any other system malfunction


Provides useful features such as redo,undo
 Atomicity

Atomic transaction:

Indivisible & irreducible series of operations

Either all occur, or nothing occurs

Ensures data consistency


Eg: money transfer from one bank acc to another
 Durability

Transactions that have been commited will
survive permanently

Achieved by flushing transaction’s records to
non- volatile storage before acknowledging
commitment
 Functioning

//Image will come here


Log is a sequence og log records,recording all the
update activities in the database
 Syntax of Log Record

<Ti start>

<Ti, Xj, V1,V2>

<Ti commit> or <Ti abort>


Ti:transaction id

Xj memory location

V1: old value

V2: new value

T0: transfer $50 from bank acc A to B

ie,T0: read(A);

A=A-50;

write(A);

read(B);

B=B-50;

write(B);

Let money in acc A be $1000,in B be $2000

Log record for T0

<T0 start>

<T0,A,950>

<T0,B,2050>

<T0 commit>
 Two Types of DB modifications


Deffered: Values are updated in a DB after
transaction has been commited.

Immediate: Values are updated before commit.
 How is data recovered
(deferred DB modification)

Let accounts A,B,C have money $100,$200,$300 resp.

Transaction T0: transfers $50 from A to B

Transaction T1: deposits $50 in C

T1 takes place after T0

Log record:

<T0 start>

<T0, A, 50>

<T0, B, 250>

<T0 commit>

<T1 start>

<T1, C, 350>

<T1 commit>
 Possible cases during powerloss

Incomplete T0 Incomplete T1 Both complete

<T0 start> <T0 start> <T0 start>


<T0, A, 50> <T0, A, 50> <T0, A, 50>

<T0, B, 250> <T0, B, 250> <T0, B, 250>

<T0 commit> <T0 commit>

<T1 start> <T1 start>

<T1, C, 350> <T1, C, 350>

<T1 commit>
 If No Log Record Was Used.....

If data was modified directly in database

Data can become dirty if T0 was incomplete

i.e. money could have been lost

T0:read(A);

A=A-50;

write(A);

//Power cut/malfunctioning here

//Below part not executed

read(B);

B=B-50;

write(B);
 Immediate DB Modification

Immediately after an update statement in written in log, value is updated in DB


<T0 start>

<T0, A, 100, 50> //A updated in DB

<T0, B, 200, 250> //B updated in DB

<T0 commit>

<T1 start>

<T1, C, 300, 350> //C updated in DB

<T1 commit>
 Failure Handling


<T0 start>

<T0, A, 100, 50> //A updated in DB

//Failure at this point, below log not registered

<T0, B, 200, 250> //B updated in DB

<T0 commit>

<T1 start>

<T1, C, 300, 350> //C updated in DB

<T1 commit>



Seeing the old value transaction is rolled back
 undo/redo

UNDO:

undo(Ti) restores the values of all data items updated by
transacion Ti to old values

Ti needs to be undone if log contains <Ti start>

but not <Ti commit>

REDO:

redo(Ti) sets the value of all data updated by Ti to the new values

Ti needs to be redone if the log contains both <Ti start>

and <Ti commit>

Case1: Case2: Case 3:

<T0 start> <T0 start> <T0 start>


<T0, A, 50> <T0, A, 50> <T0, A, 50>

<T0, B, 250> <T0, B, 250> <T0, B, 250>

<T0 commit> <T0 commit>

<T1 start> <T1 start>

<T1, C, 350> <T1, C, 350>

<T1 commit>
Case1: T0 undone

Case 2: T0 redone, T1 undone

Case 3: both redone

 Checkpoints

When a system failure occurs we need to
search the entire log to determine transactions
that need to be undone & redone.

But this process is time consuming.

To reduce time consumed checkpoints are
used.

Check points require the following processes to
take place:

Output onto the stable storage all log records
currently residing in main memory

Output to disk all modified buffer blocks

Output on to stable storage a log record
<checkpoint>
 Advantages

WAL is significantly faster in most scenarios

Disk I/O operations tend to be more sequencial

WAL provides more concurrency
 Disadvantages

All processes using a DB must be on the same
host computer

As a result, WAL does not workover a network
filesystem

Thank you