Search code examples
databasecommitdistributed-transactionsundo-redodata-recovery

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


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


Solution

  • 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. enter image description here

    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