Logging and Buffering - Transaction Processing - page 45

updated database page can be flushed onto disk only if all the log records up to
and including the log record for the last update on the page have already been
flushed onto disk. Besides the WA L protocol and the flushing of the log as part
of the commit protocol, no further restrictions are imposed on buffering, so that
pages containing uncommitted updates can be “stolen” (i.e., flushed onto disk)
and that no database page need be “forced” (i.e., flushed onto disk) at transaction
commit.

3.1 Transaction Log

The transaction log keeps a record of all updates made by transactions to the
database, that is, W and W 1 actions in the read-write model and I , D, I 1 ,and
D 1 actions in the key-range model are recorded in the log. Also, when a transaction
begins, commits, aborts, completes its rollback, sets a savepoint, begins rollback to
a savepoint, or completes rollback to a savepoint (actions B, C , A, SŒP, AŒP ,
CŒP), this is logged. Other log records include those for structure modifications
and checkpoints.
The log is an entry-sequenced ,or append-only , file into which the log records of
all transactions are appended in the chronological order of the updates. Log records
can be deleted from the log only by truncating the log from the head, disposing of
old log records that are no longer needed. The writes to the log file are buffered
in a log buffer , whose contents are flushed when some transaction commits or
the buffer becomes full or when the buffering policy (WAL) states that so must be
done.
Because the log is shared by all transactions in the system, appending to the log
must be protected by an exclusive latch, which is held for the time of appending
the log record into the log buffer. Because the log buffer is flushed at every
transaction commit (or completion of rollback), every transaction, be it forward-
rolling, backward-rolling, committed or rolled back, is guaranteed to have on the
log disk all its log records written before the last commit of some transaction.
As was mentioned earlier, each log record receives a unique log sequence
number ,the LSN , which is determined while holding the exclusive latch on the
log tail. In a centralized database system, the log sequence numbers form a single
increasing sequence: if action o 0 of transaction T 0 is performed after action o of
transaction T ,then LSN .o/ < LSN .o 0 /.
In a shared-disks or page-server system, where sites (clients) independently
generate log records for the actions they perform on the shared database, the log
sequence numbers cannot be globally increasing. However, the LSN s of updates that
are performed on the same page must always form a sequence that increases with
time.
Log sequence numbers are often generated so that they also act as direct
addresses to the log records. A structure that is often used is a pair containing the
number of the log file and the byte offset. The byte offset represents the distance of