The next figure shows the log corresponding to a particular schedule. The crash occurs immediately after the last operation.
[start_transaction T1]
[write_item, T1, B, 10, 20]
[commit, T1]
[checkpoint]
[start_transaction T2]
[start_transaction T3]
[read_item, T2, A]
[read_item, T2, B]
[write_item, T3, A, 20, 30]
[write_item, T3, C, 20, 10]
[start_transaction T4]
[commit, T3]
[read_item, T2, D]
[write_item, T4, C, 10, 30]
[write_item, T4, D, 20, 30]
---- system crash ----
a) Use the write_item operations to figure out the values of the items A, B, C, D at the time of the checkpoint.
b) What are the values of the items A, B, C, D at the time of the crash point?
c) Describe the recovery process assuming immediate updates and the UNDO / REDO algorithm.
d) Describe the recovery process assuming deferred updates and the NO-UNDO / REDO algorithm.
In both recovery cases, specify which transactions are rolled back, which operations are redone (if any), and which operations are undone (if any).
write_item(T, x, old_value, new_value)
(a)value of item A = 20
value of item B = 20 (written by transaction T1 before
checkpoint)
value of item C = 20
value of item D = 20
(b)At the time of the crash point
value of item A = 30
value of item B = 20 (written by transaction T1 before
checkpoint)
value of item C = 30
value of item D = 30
(c)In the immediate update, the database may be updated by some
operations of a transaction before the transaction reaches its
commit point. However, these operations are recorded in a log on
disk before they are applied to the database, making recovery still
possible. If a transaction fails to reach its commit point, the
effect of its operation must be undone i.e. the transaction must be
rolled back hence we require both undo and redo.
Transaction T1 committed before checkpoint(nothing to do to T1)
Transaction T2 started after checkpoint but not committed till crash .Therefore ,T2 must be undone( transactions T2 have to be rolled back to undo their effect on the database during the recovery process)
Transaction T3 started after checkpoint and committed before crash .Therefore ,T3 must be redone( transactions T3 have to be redone)
Transaction T4 started after checkpoint but not committed till crash .Therefore ,T4 must be undone( transactions T4 have to be rolled back to undo their effect on the database during the recovery process)
(d)Deferred update technique does not physically update the database on disk until a transaction has reached its commit point. Before reaching commit, all transaction updates are recorded in the local transaction workspace. If a transaction fails before reaching its commit point, it will not have changed the database in any way so UNDO is not needed. It may be necessary to REDO the effect of the operations that are recorded in the local transaction workspace, because their effect may not yet have been written in the database.
Transaction T1 committed before checkpoint(nothing to do to
T1)
Transaction T2 started after checkpoint but not committed till
crash (nothing to do to T2)
Transaction T3 started after checkpoint and committed before crash
.Therefore ,T3 must be redone( transactions T3 have to be
redone)
Transaction T4 started after checkpoint but not committed till crash (nothing to do to T4)
The next figure shows the log corresponding to a particular schedule. The crash occurs immediately after...