Information Technology Reference
In-Depth Information
For reasons of efficiency, a modified page is not taken onto the disk immediately
after the update operation has been performed nor even after the transaction that
updated the page has committed. A page that is used often is kept in the buffer as
long as possible, according to the
LRU
principle. Thus, the buffer version of a page
may accumulate many updates, and the disk version can lag far behind the buffer
version.
For example, some page may receive updates from a thousand transactions run
in succession. It may then very well happen that the page is not once flushed onto
disk in between, in which case the disk version lags a thousand updates behind the
current version of the page.
2.5
Database Recovery and Checkpoints
In a system crash or shutdown, the contents of main memory disappear, including
the buffers: the database buffer and the log buffer. Only the disk version of the
database remains, with the log records that were taken to disk before the crash. The
disk version usually does not reflect the state of the database at the time of the failure
but may lag more or less behind.
Transactions have written log records for all the updates they have performed,
and the
write-ahead-logging
(
WA L
) protocol ensures that log records for all the
updates in the disk version of the database are found on the log disk (see Chap.
3
).
Moreover, the commit of a transaction includes writing a “commit” log record and
flushing the log buffer onto the log disk, so that in the event of a system crash the
log disk always contains log records up to and including the “commit” log record of
the last transaction that committed before the failure.
In
restart recovery
(see Chap.
4
), the database system is restarted, and the state
of the database that existed at the time when the last log record found on the log
disk was written is restored from the disk versions of the database pages and the
log records: the pages that have updates recorded in the log are fetched from disk
in the buffer, and the updates described by the log records are applied on the pages
(Sects.
4.7
and
4.8
). In addition, all forward-rolling transactions, that is, those for
which no “abort” or “commit” log record is found on the log disk, are aborted
and rolled back, and the rollback of all backward-rolling transactions is run into
completion (Sect.
4.9
).
To speed up restart recovery, modified pages are flushed from the buffer onto
disk in
checkpoints
(Sect.
4.4
) taken periodically (typically in every 5-10 min).
Immediately after flushing onto disk, thediskversionofthepagehasthesame
contents as the current version (i.e., the buffer version) of the page.
In a
complete checkpoint
, all modified pages in the buffer are flushed onto disk.
After a complete checkpoint, the state of the disk version of the database is the same
as the current state of the database, unless updating the database is permitted during
the checkpoint (which it usually is, however).
Taking a complete checkpoint significantly slows down transaction processing.
A more light-weight procedure for speeding up restart recovery is an
indirect
