The Gateway to Computer Science Excellence
0 votes
55 views
In crash recovery in the checkpoint mechanism. Till the last checkpoint for all committed transactions redo will be done and all uncommited transactions undo is done. Can anyone explain what is the reason behind it ?
in Databases by Active (1.9k points)
retagged by | 55 views

1 Answer

+2 votes
Best answer

generally our database kept on secondary storage ( our assumption is Secondary storage never crash )

Check points means till that point everything written into the disk !

Note transaction completes means either committed or aborted !

Before the check point may some of the transactions completed, some of the transactions were not completed !

Checkpoints have a List which contains every transaction which is not completed at that point.

after the checkpoints, either a transactions starts, read, modify, committed or aborted or nothing specified , we just write into the LOG, and carried out the effects into the secondary storage.

Now, let crash is happens, ==> our main memory crashes, ( Note that LOG is also kept on secondary storage, so LOG never lost ! )

therefore we need to restore our Database back to the original consistent position.

in this case you can go upto the Checkpoint and restore it back, But note that after checkpoints some of the transactions are completed, and some of the not completed transactions is still running. and some of transactions are newly started and completed !

those non-completed transactions executes partially ==> for getting consistent state, we have to revert every operation of those transaction, So we keep those transactions in UNDO list.

those completed transactions, we have to keep their update effect into the database. ==> for getting consistent state we need to REDO the operations of the transactions, So we keep those transactions in REDO list.

Some people think why we have to keep REDO list, actually we follow buffer system to update the database, i mean when buffer full, then only those operations carried out into the Secondary storage, So before Buffer full may crash happens, So safe side we will keep REDO list.

 

Practice :- https://gateoverflow.in/8246/gate2015-2-46

(start, T4); (write, T4, y, 2, 3); (start, T1); (commit, T4); (write, T1, z, 5, 7);

(checkpoint);

(start, T2); (write, T2, x, 1, 9); (commit, T2); (start, T3); (write, T3, z, 7, 2); 

Before Checkpoint T$_4$  committed, So don't worry about it !

Check point have the list, which contains only T$_1$ due to only T$_1$ is activated at that time.

after check point, T$_2$ started and completed ===> keep it in REDO list

after check point, T$_3$ started but not completed ===> keep it in UNDO list

in the list of CHECK Point, take each transaction and

if that Transactions is completed add it into REDO list.

if that Transactions is not completed add it into UNDO list. ===> T$_1$ is in UNDO list.

 

Note that First we have do UNDO list ==> system back to some consistence state then we have to do REDO list.

REDO list should preserve the order. I mean after check point if T$_i$ completed first, after that T$_j$ completed, then while recovery you have to do first T$_i$ after that T$_j$.

still you have doubts :- https://www.youtube.com/channel/UCZp6-HMUFJtEUiJxGSJeeQA/videos

by Veteran (65.6k points)
selected by
Quick search syntax
tags tag:apple
author user:martin
title title:apple
content content:apple
exclude -tag:apple
force match +apple
views views:100
score score:10
answers answers:2
is accepted isaccepted:true
is closed isclosed:true
50,737 questions
57,292 answers
198,225 comments
104,909 users