8.7k views

Consider the following log sequence of two transactions on a bank account, with initial balance $12000,$ that transfer $2000$ to a mortgage payment and then apply a $5\%$ interest.

1. T1 start
2. T1 B old $=1200$ new $=10000$
3. T1 M old $=0$ new $=2000$
4. T1 commit
5. T2 start
6. T2 B old $=10000$ new $=10500$
7. T2 commit

Suppose the database system crashes just before log record $7$ is written. When  the system is restarted, which one statement is true of the recovery procedure?

1. We must redo log record $6$ to set B to $10500$
2. We must undo log record $6$ to set B to $10000$ and then redo log records 2  and 3
3. We need not redo log records $2$ and $3$ because transaction T1 has committed
4. We can apply redo and undo operations in arbitrary order because they are idempotent

edited | 8.7k views
+2
not 1200  but 12000 .. value is wrong for B old
+1
yes, i think it's typing mistake.
+8

upto 15:15

0

thanks bro.really helped.

0
Is this topic still in syllabus?? Because it is in recovery system chapter in korth which i think is not in syllabus.. Correct me if iam wrong...
0

(In Case the video is not opening.)

So, once the crash happens the log is read backwards up to the checkpoint and the ... So, this
is read backwards this is very importantly, this is read backwards up to the checkpoint and the
following thing is done , if there is a (commit, Ti) is found in this backward scan then there is
a redo list, where Ti is added to the redo list. Now, on this scanning backward if suppose on
the other hand somebody founds the (start, Tj) then there is an undo list, where Tj is added.

And suppose there is some other Tk which started earlier ... Now, note that scanning of the log
goes only up to the checkpoint, however, what will happen is that since Tk started before the
checkpoint and has not committed, Tk must appear somewhere in this TL. So, this is, must be
in the active, in the list of active transactions, so this is the list of active transactions. So, Tk
must be appearing somewhere in that. So, Tk is not found using this scanning, but Tk is in the
active list, then Tk is also added to the undoing list.

Of course, if Tk has not been in the redo list; that means, Tk there is no commit Tk entry of
this, if there is (commit, Tk) entry, then Tk would have been added to the redo list then nothing needs to be done. But, otherwise Tk needs to be added to the undo list. So, this is the way how
the redo list and the undo list are being made and then we follow the same thing. So, undos
are first done in a reverse order and then the redos are being done in a forward order.

So, the transactions in the undo list are first revert it back in the reverse order as they appear
in the log and the transactions in the redo list are then done in the forward order as they
appear in the log. And one more thing only the operations after the checkpoint, so, this is read
only up to the checkpoint, so, only the operations after the checkpoint needs to be either
undone or redone, that is it, because before that everything has been either undone or redone
correctly.

Answer should be B. Here we are not using checkpoints so, redo log records $2$ and $3$ and undo log record $6$.
Consider the following steps taken from the book 'Navathe':

PROCEDURE RIU_M

1. Use two lists of transactions maintained by the system: the committed transactions since the last checkpoint and the active transactions
2. Undo all the $write$_$item$ operations of the $active$ (uncommitted) transaction, using the UNDO procedure. The operations should be undone in the reverse order in which they were written into the log.
3. Redo all the $write$_$item$ operations of the $committed$ transactions from the log, in the order in which they were written into the log.
by Boss (31.4k points)
edited
+1
@pooja

if we are using check point after 6 statement then we have to redo statement 6..am i right?
0
but answer is given option c ...
i think option a and option c   both should be the answer .... plz clarify
+1
@Pooja, what is the difference in recovery procedures if checkpoints are/ are not used?
+3
@Ayush Upadhyaya, If we are not using checkpoint then it implies that after commit, changes will be made to log file only(not immediately to the disk DB) and if using checkpoints then changes will be made permanently and immediately, when checkpoint encountered, to the database.
+1
committed tx never rollback.
0
Actually checkpoints speed up the recovery process as sometime log file becomes so huge that that redo and undo operation takes more time ...
0
@akash

if we are using check point after 6 statement then we have to redo statement 6..am i right?

No we can't redo log 6 because checkpoint is used for fast recovery of database,

According to that checkpoint checks the transaction which are committed do it Undo and the transaction which are started but not yet commited all get redo.
0

I don't understand the need (or rather can't think of a use case) of redoing the committed transactions.

According to me,

• In Deferred database modification, just restart of uncommitted transaction will do.
• In Immediate database modification, undo and then restart of uncommitted transactions will do.

Checkpoint : Checkpoint is a mechanism where all the previous logs are removed from the system and stored permanently in a storage disk. Checkpoint declares a point before which the DBMS was in consistent state, and all the transactions were committed.

When a system with concurrent transactions crashes and recovers, it behaves in the following manner −

=>The recovery system reads the logs backwards from the end to the last checkpoint.

=>It maintains two lists, an undo-list and a redo-list.

=>If the recovery system sees a log with <tn, start=""> and <tn, commit=""> or just <tn, commit="">, it puts the transaction in the redo-list.

=>If the recovery system sees a log with <tn, start=""> but no commit or abort log found, it puts the transaction in undo-list.

All the transactions in the undo-list are then undone and their logs are removed. All the transactions in the redo-list and their previous logs are removed and then redone before saving their logs

so we must undo log record 6 to set B to 10000 and then redo log records 2 and 3 because system fail before commit operation. So we need to undone active transactions(T2) and redo committed transactions (T1)

So Answer is B redo log records 2 and 3 and undo log record 6

by Boss (41.2k points)
edited
+1

Second Last Paragraph:  All the transactions in the redo-list and their previous logs are removed and then redone before saving their logs ??

What do you mean by this??

+1

@Shaik Masthan

If the recovery system sees a log with <tn, start=""> and <tn, commit=""> or just <tn, commit="">, it puts the transaction in the redo-list

If log sees <Tx start>...<Tx,abort >  then it will be added to REDO list right ??

0

@jatin khachane 1

yes ! But think,

" is there any problem if i add abort transactions to UNDO-LIST ? " ---- NO problem

" is there any problem if i doesn't add abort transactions to either UNDO-LIST or REDO-LIST ? (i.e., simply ignoring ) " --- yes, problem arises !

The database can be modified using two approaches by executing logs:

1. Deferred database modification: permanent database update happens when transaction commits and only new values needs in logs.
2. Immediate database modification: permanent database update happens immediately and old and new both values needs in logs.

By looking on logs and options in this question, it seems to follow immediate database modification. It means till crash of system, few of log records has written in database. But system do not know after crashing that how many log records already written in database.

So after restart system, undo all uncommitted transactions like T2 (reverse log record 6 to set B back to 10000) and then redo all committed transactions like T1 (log records 2 and 3). Thus, it needs to undone active transactions (T2) and redo committed transactions (T1). Process Steps:

1. Go to log record (vii) where system crashed and reads the logs backwards.
2. If find some committed transaction then puts to Redo List; If find some uncommitted transaction then executes its logs in reverse like T2 writes B to 10000.
3. Redo T1's log records like write B to 10000 and M to 2000 without caring already existing values of A & B in database.

Answer obviously is B. No need to discuss checkpoints for answer of this question.

by Active (2.4k points)
edited
0
Yes correct. It is immediate database modification because "old values" are mentioned.
We must undo log record 6 to set B to 10000 and then redo log records 2  and 3 bcoz system fail before commit operation. So we need to undone active transactions(T2) and redo committed transactions (T1). https://gateoverflow.in/8246/gate2015-2_46
by Veteran (60.9k points)

For recovery, we'll be having 2 choices, either Deferred updation or Immediate updation techniquee.

Now If we take Deferred Updation which says only REDO and no UNDO then no option is matching.Then we'll take Immediate Updation, which is having two choices further as UNDO/No-REDO and UNDO/REDO.

If we follow UNDO/No-REDO then we'll have to UNDO active transaction T2 only (no REDO on T1 as changes are immediate to DB and T1 already committed).Again no option matches with this choice.

So we'll follow UNDO/REDO which says that all committed transactions up to checkpoint need not be REDO, committed but not checkpointed are need to be REDO and active transaction need to be UNDO.Hence T2 needs UNDO and then T1 needs REDO. Thus, answer is option B

by Active (1.9k points)
0

"Now If we take Deferred Updation which says only REDO and no UNDO then no option is matching."  Here how option A is not matching?

0
Okay. I think I got it. Is it because if it was deferred then record 2 and 3 needed to be redone and not record 6 ?
0
@MiNiPanda, Yes, you are ryt...and REDO must be applied to committed operations only...

The log file given in question is example of  type deferred update mode. In this case, old value and new value of a variable is stored. If a transactions is not committed, its operations need to be undone and if a transaction is committed, its operations need to be redone. But first we need to undone the uncommitted transaction and then redone the committed transaction. Because if we undo the uncommitted transaction later, the value updated by committed transaction may be lost. So the correct option is B.

Good explanation

by Active (4.7k points)

Up until the checkpoint, do nothing.

For the logs after the checkpoint (which is the case here, we see no checkpoints) undo all uncommitted transactions, and redo all committed transactions.

A is wrong, because we have to undo record 6, not redo.

B is correct.

C is wrong, because we redo committed transactions that are not checkpointed. (We see no checkpoint here)

D is just extremely stupid. Would lead to race condition / data inconsistency.

by Loyal (6.4k points)
C.

Once a transaction is committed, no need to redo or undo operations
by Junior (715 points)
+3
ans should be B here we arent using checkpoints so redo  log records 2 and 3 and undo log record 6