The solution to this problem, deferred rollback, was introduced in Oracle 7.3. Oracle
opens the database after the rollforward phase of recovery and performs the
rollback of uncommitted transactions in the background. This process reduces database
downtime and helps to reduce the variability of recovery times by deferring the
rollback phase.
But what if a user??™s transaction begins working in a database block that contains
some changes left behind by an uncommitted transaction? If this happens, the user??™s
transaction will trigger a foreground rollback to undo the changes and will then proceed
when rollback is complete. This action is transparent to the user??”he doesn??™t
receive error messages or have to resubmit the transaction.
Oracle8i further optimized the deferred rollback process by limiting the rollback triggered
by a user transaction to the block in which the transaction is interested. For
example, suppose there is a large uncommitted transaction that affected 500 database
blocks. Prior to Oracle8i, the first user transaction that touched one of those
500 blocks would trigger a foreground rollback and absorb the overhead of rolling
back the entire transaction.
Pages:
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575