6.8k 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 | 6.8k views
+2
not 1200  but 12000 .. value is wrong for B old
+1
yes, i think it's typing mistake.

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.
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?
+1
@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

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.

edited
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

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

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

C.

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

1
2