Selective or Deferred Restart

• Sometimes, after a system failure, we may wish to restart the processing of new transactions as soon as possible.
• Hence, we may wish to defer doing some recovery work to a later point in time.
• This is usually done to reduce the amount of time during which some critical data is unavailable.
• This is accomplished by recovering such data first and then opening the system for the processing of new transactions.

• If none of the objects to be recovered is offline, but it is desired that the processing of new transactions start before the rollbacks of the loser transactions are completed, then we can accommodate it by doing the following:

  1) First repeat history and reacquire, based on their log records, the locks for the uncommitted updates of the loser and in-doubt transactions, and

  2) then start processing new transactions even as the rollbacks of loser transactions are performed in parallel.

  The locks acquired in step (1) are released as each loser transaction's rollback completes.