CODEWITHSUNDEEP
databasecommitdistributed-transactionsundo-redodata-recovery
Raj Shah
Raj Shah

Reputation: 846

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

Upvotes: 3

Views: 986

Answers (2)

Ashish Aggarwal
Ashish Aggarwal

Reputation: 335

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

Upvotes: 1

Kishan Kumar
Kishan Kumar

Reputation: 709

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.

Upvotes: 0

Related Questions