Logging and Buffering - Transaction Processing - page 60

appear in the disk version of the database, they may appear in the buffer version of
the database reconstructed in the redo pass and hence must be undone in the undo
pass that follows.
The no-steal policy might be of some use in the context of do-undo-redo recovery,
in which the undo pass precedes the redo pass, so that the updates by aborted
transactions lost due to the failure are not redone. But, as shown in Sect. 4.5 , do-
undo-redo recovery is problematic in fine-grained transaction processing in which a
data page can simultaneously hold updates by several active transactions.
An obvious downside of the no-steal policy is that the buffer pool must be large
enough to accommodate all the pages that have been updated by active transactions.
Moreover, in fine-grained transaction processing a frequently updated page may
continue to hold dirty data besides the committed data, so that, under the no-steal
policy, the page cannot be flushed. This again implies that the disk version of the
database lags more and more behind the current version of the database, so that
more work must be done in the redo pass of recovery (see Sects. 4.6 and 4.8 ). This
is why most database management systems apply the steal policy instead.
As for the question when should clean data be taken to disk, there are two
different policies: force and no force. In the force policy , when a transaction requests
to be committed or to complete its rollback, the buffer manager finds all pages that
have been updated by the transaction but have not yet been flushed onto disk, and
“forces,” that is, flushes them onto disk (using WA L ). Only after this, the transaction
actually commits or completes its rollback, that is, the commit log record for the
transaction is logged and the log is flushed onto the log disk. The no-force policy
specifies that both dirty and clean modified data can stay in the buffer for as long
as the buffer space is not needed for other purposes. Under fine-grained transaction
processing, a page that holds data updated by a committing transaction may also
hold data updated by other active transactions, in which case the force policy also
takes dirty data onto disk, besides the clean data, or, more accurately, the data that
is about to turn from dirty to clean.
The force policy obviously makes the redo pass of failure recovery faster.
However, it slows down the commit action: updated pages are flushed onto disk
as part of the commit protocol. An even more serious disadvantage is that a page
that is updated repeatedly by different transactions is unnecessarily taken to disk
each time one of the transactions commits. In the no-force policy, such a page (a
“hotspot” page) would probably stay in the buffer between transactions and would
not need to be taken to disk. This is why most database management systems use
the no-force policy.

3.10 Reducing Disk Access

The buffer manager should try to minimize the number of disk accesses performed
during transaction processing. When the buffer becomes full, the page to be evicted
from the buffer should be selected intelligently. In managing virtual memory, the