System Architecture 2-153
Physical Log
Blobspace blobpages do not appear in the physical log because blobs are
logged differently than all other data types. (For further information about
blobspace logging, refer to page 4-22.)
The first time following a checkpoint that a page is modified, the “before-
image” of the page is written to the physical log buffer in shared memory.
Before the modified page can be flushed to disk from the shared-memory
buffer pool, the “before-image” of the page must be flushed from the physical
log buffer to the physical log. Only the first modification causes a “before-
image” to be written to the physical log. These precise rules are required for
fast recovery. (Refer to page 2-73 for more details about required coordi-
nation for writing “before-images” and flushing the logical log buffer.)
The physical log begins filling after each OnLine checkpoint. Immediately
after the checkpoint occurs, OnLine data is at a point of known physical
consistency,and the physical log “before-images” are nolonger needed.(This
is true even for ongoing transactions. If a transaction must be rolled back, all
the information required for the rollback is contained in the logical log files.)
The checkpoint procedure empties the physical log by resetting a pointer in
the physical log that marks the beginning of the next group of required
“before-images.” OnLine manages the physical log as a circular file,
constantly overwriting unneeded data.
The checkpoint procedure is the only mechanism that empties the physical
log. If the physical log becomes 75 percent full, this event, in itself, initiates a
checkpoint.
The physical log should not fill during a checkpoint if you have followed the
sizing guidelines for the physical log and the logical log files. However, it is
possible to imagine a scenario in which this could occur.
Under normal processing, once a checkpoint is requested and the checkpoint
begins, all user processes are prevented from entering critical sections of
code. (Refer to page 2-27 for more details about critical sections.) However,
user processes currently in critical sections can continue processing. It is
possible for the physical log to become full if many processes in critical
sections are processing work and if the space remaining in the physical log is
very small. The many writes performed as processes completed their critical
section processing could conceivably fill the physical log.