Logging and Buffering - Transaction Processing - page 59

commit or all abort and roll back. The management of distributed transactions is
discussed in Chap. 13 .

3.9 The Steal-and-No-Force Buffering Policy

As explained earlier, the buffer manager of the database management sys-
tem services the page-fixing and page-latching calls ( fix-and-read-latch .p/,
fix-and-write-latch .p/, unlatch-and-unfix .p/) of server-process threads that access
the database and generally takes care that the database pages are easily available
when needed. We also recall that the buffer has space for only a relatively small
number of database pages at a time. The size of the buffer varies, but it is rarely
larger than a few thousand pages.
Pages that are fixed in the buffer and the rules for writing log records prevent
the buffer manager from removing pages freely from the buffer when it is full. A
page that is currently fixed for a server-process thread that is executing a transaction
cannot be evicted from the buffer. According to the WA L protocol, a modified
database page can be taken to disk only after the log records for the updates have
beentakentodisk.
On the other hand, the commit protocol of a transaction (and the protocol
for completing rollback) includes flushing the log to disk (force-log-at-commit).
Usually, the database management system does not place further restrictions
on buffer management. However, in some special-purpose database management
systems, the buffer manager may apply a more limited protocol.
A data item (tuple or relation) of the logical database is dirty , if the transaction
that updated it last is still active, and clean , if the transaction that updated it last
has committed or completed its rollback. An updated database page is dirty ,ifit
contains dirty data items, and clean otherwise.
When selecting an unfixed page for flushing from the buffer onto disk, the buffer
manager can make a difference between dirty and clean pages or ignore the state
of the page. In the latter case, the buffer manager applies the steal policy :itis
allowed to “steal” the page from the buffer to disk, even though some transactions
that updated the tuples on the page are still active. The other choice is the no-steal
policy , according to which all dirty pages are kept in the buffer until the transactions
that updated the pages have all committed or rolled back.
The no-steal policy may be claimed to make the undo pass of restart recovery
faster: because dirty data is never taken onto disk, the recovery process might have
less work in performing the undo actions of backward-rolling transactions that are
aborted because of the failure. However, with the do-redo-undo recovery paradigm
followed by the ARIES algorithm (see Sect. 4.6 ), the no-steal policy would yield
little or no benefit, because a redo pass is run first in which all updates (be them by
committed or rolled-back or active transactions) are redone (if found missing from
the disk version), and only then an undo pass is run in which undo actions by aborted
transactions are performed. Thus, even if the updates by aborted transactions do not