{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

The execution of these operations can be performed as

Info iconThis preview shows pages 6–8. Sign up to view the full content.

View Full Document Right Arrow Icon
other similar operations) which must be performed after commit. The execution of these operations can be performed as a transaction and log records generated, following by a post-commit log record which indicates that post commit processing has been completed for the transaction. During recovery, if a commit log record is found with post-commit actions, but no post-commit log record is found, the effects of any partial execution of post-commit operations are rolled back during recovery, and the post commit operations are reexecuted at the end of recovery. If the post-commit log record is found, the post-commit actions are not reexecuted. Thus, the actions are guaranteed to be executed exactly once. The problem of clashes on primary key values can be solved by holding key-level locks so that no other transaction can use the key till the first transaction completes. 16.10 Explain the reasons why recovery of interactive transactions is more dif- ficult to deal with than is recovery of batch transactions. Is there a simple way to deal with this difficulty? (Hint: Consider an automatic teller ma- chine transaction in which cash is withdrawn.) Answer: Interactive transactions are more difficult to recover from than batch transactions because some actions may be irrevocable. For example, an output (write) statement may have fired a missile, or caused a bank machine to give money to a customer. The best way to deal with this is to try to do all output statements at the end of the transaction. That way if the transaction aborts in the middle, no harm will be have been done. Output operations should ideally be done atomically; for example, ATM machines often count out notes, and deliver all the notes together instead of delivering notes one-at-a-time. If output operations cannot be done atomically, a physical log of output operations, such as a disk log of events, or even a video log of what happened in the physical world can be
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
Practice Exercises 21 maintained, to allow perform recovery to be performed manually later, for example by crediting cash back to a customers account. 16.11 Sometimes a transaction has to be undone after it has committed because it was erroneously executed, for example because of erroneous input by a bank teller. a. Give an example to show that using the normal transaction undo mechanism to undo such a transaction could lead to an inconsistent state. b. One way to handle this situation is to bring the whole database to a state prior to the commit of the erroneous transaction (called point-in-time recovery). Transactions that committed later have their effects rolled back with this scheme. Suggest a modification to the recovery algorithm of Section 16.4 to implement point-in-time recovery using database dumps. c. Later nonerroneous transactions can be re-executed logically, if the updates are available in the form of SQL but cannot be re-executed using their log records. Why?
Background image of page 7
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}