A 1000 900 3 t 2 start 4 t 2 a 1000 2000 5 t 2 commit

Info iconThis preview shows pages 4–7. Sign up to view the full content.

View Full Document Right Arrow Icon
, A, 1000, 900> 3. < T 2 start> 4. < T 2 , A, 1000, 2000> 5. < T 2 commit> A rollback actually happened between steps 2 and 3, but there are no log records re²ecting the same. Now, this log data is processed by the recovery algorithm. At the end of the redo phase, T 1 would get added to the undo-list, and the value of A would be 2000. During the undo phase,
Background image of page 4

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Practice Exercises 19 since T 1 is present in the undo-list, the recovery algorithm does an undo of statement 2 and A takes the value 1000. The update made by T 2 , though commited, is lost. The correct sequence of logs is as follows: 1. < T 1 start> 2. < T 1 , A, 1000, 900> 3. < T 1 , A, 1000> 4. < T 1 abort> 5. < T 2 start> 6. < T 2 , A, 1000, 2000> 7. < T 2 commit> This would make sure that T 1 would not get added to the undo-list after the redo phase. 16.8 Disk space allocated to a Fle as a result of a transaction should not be released even if the transaction is rolled back. Explain why, and explain how ARIES ensures that such actions are not rolled back. Answer: If a transaction allocates a page to a relation, even if the transac- tion is rolled back, the page allocation should not be undone because other transactions may have stored records in the same page. Such operations that should not be undone are called nested top actions in ARIES. They can be modeled as operations whose undo action does nothing. In ARIES such operations are implemented by creating a dummy CLR whose Un- doNextLSN is set such that the transaction rollback skips the log records generated by the operation. 16.9 Suppose a transaction deletes a record, and the free space generated thus is allocated to a record inserted by another transaction, even before the Frst transaction commits. a. What problem can occur if the Frst transaction needs to be rolled back? b. Would this problem be an issue if page-level locking is used instead of tuple-level locking? c. Suggest how to solve this problem while supporting tuple-level locking, by logging post-commit actions in special log records, and executing them after commit. Make sure your scheme ensures that such actions are performed exactly once. Answer: a. If the Frst transaction needs to be rolled back, the tuple deleted by that transaction will have to be restored. If undo is performed in the usual physical manner using the old values of data items, the space allocated to the new tuple would get overwritten by the transaction
Background image of page 5
20 Chapter 16 Recovery System undo, damaging the new tuples, and associated data structures on the disk block. This means that a logical undo operation has to be performed i.e., an insert has to be performed to undo the delete, which complicates recovery. On related note, if the second transaction inserts with the same key, integrity constraints might be violated on rollback. b.
Background image of page 6

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 7
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page4 / 8

A 1000 900 3 T 2 start 4 T 2 A 1000 2000 5 T 2 commit A...

This preview shows document pages 4 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online