Deferred Database Modification
- The most widely used structure for recording database modification is the log.
- The log is a sequence of log records, recording all the update activities in the database.
- In short Transaction log is a journal or simply a data file, which contains the history of all transaction performed and maintained on stable storage.
- Updates (changes) to the database deferred (or postponed) until the transaction commits.
- During the execution of the transaction, updates recorded only in the transaction log and in buffers. After the transaction commits, these updates are recorded in the database.
When failure occurs
- If the transaction has not committed, then it has not affected the database. And so, no need to do any undoing operations. Just restart the transaction.
- If a transaction has committed, then, still, it may not have modified the database. And so, redo the updates of the transaction. Transaction Log
- In this technique, the transaction log used in following ways:
- Transaction T starts by writing <T start> to the log.
- Any update is recorded as <T, X, V>, where V indicates the new value for data item X. Here, no need to preserve old value of the changed data item. Also, V not written to the X in a database, but it deferred.
- Transaction T commits by writing <T commit> to the log. Once this entered in the log, actual updates recorded to the database.
- If a transaction T aborts, the transaction log record ignored, and no any updates recorded to the database.
Example for Deferred Database Modification
Consider the following two transactions, T0 and T1 given in the figure, where T0 executes before T1. Also consider that initial values for A, B and C are 500, 600 and 700 respectively.
The following figure shows the transaction log for above two transactions at three different instances of time.
If failure occurs in case of
- No, any REDO actions required.
- As Transaction T0 has already committed, it must redo.
- As Transactions T0 and T1 have already committed, they must redo.