In Log-Based Recovery why do we redo committed transactions?

Question

The log is a sequence of log records, which maintains information about update activities on the database. Whenever a transaction starts, reads, writes or commits it registers itself in the log with its particular action. So now when recovering from failure a transaction needs to be undone if the transaction hasn't committed and it needs to be redone if it has committed. My doubt is regarding the logic behind doing this. Why do we need to redo committed transactions?

Reference: Slide 19 - http://codex.cs.yale.edu/avi/db-book/db6/slide-dir/PPT-dir/ch16.ppt

Please start with a little more context before diving into some very specific issue. — deceze, Jul 25 '17 at 08:38
_we undo the uncommitted and then redo the committed_ - that doesn't sound right at all. — stuartd, Jul 25 '17 at 08:39
@stuartd This is what is mentioned in the book which is written by Yale university professors — Raj Shah, Jul 25 '17 at 08:50
So you did, thank you. It's a bit over my head though. Is this in reference to _partially_ completed transactions? — stuartd, Jul 25 '17 at 08:59
@stuartd Yeah this would make sense in the case of partially committed transactions but it doesn't mention anywhere that the commits mentioned are partial commits — Raj Shah, Jul 25 '17 at 09:08

score 1 · Accepted Answer · answered Sep 03 '19 at 20:12

The data changes for a committed transaction, stored in the database buffers of the SGA, are not necessarily written immediately to the datafiles by the database writer (DBWn) background process.

because they are in SGA they are visible to other users but those changes still can be lost after commit if not written to datafiles immediately.

Reference: https://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm

Reference for image: https://docs.oracle.com/cd/E17781_01/server.112/e18804/memory.htm#ADMQS174

Can you upvote the question as well if you felt it was a relevant one. Thanks — Raj Shah, Sep 05 '19 at 07:23

score 0 · Answer 2 · answered Aug 19 '17 at 10:52

It may be possible for a transaction T1 that all its log records have been output to stable storage but the actual updates on data are still in main memory. If a failure occurs at this point then redoing this transaction will ensure that all updates which were virtually lost due to failure would now get written to the stable storage.

In Log-Based Recovery why do we redo committed transactions?

2 Answers2