Filter
Top Products
System Architecture 2-73
When the Daemons Flush the Buffer Pool
When the Daemons Flush the Buffer Pool
Buffer flushing is managed by the tbinit master daemon and performed by
tbinit or by one or more tbpgcl (page-cleaner) daemons. (If no tbpgcl
daemons have been configured for your OnLine server, the tbinit daemon
performs page-cleaner functions.)
Flushing the modified shared-memory page buffers, the physical log buffer,
and the logical log buffer must be synchronized with page-cleaner activity
according to specific rules designed to maintain data consistency.
The overriding rule of buffer flushing is this: first flush the “before-images”
of modified pages to disk before you flush the modified pages themselves.
In practice, this means that the first physical log buffer is flushed and then the
buffers containing modified pages from the shared-memory buffer pool.
Therefore, even when the need to flush a shared-memory page buffer arises
because that buffer is needed by another user process (a foreground write,
refer to page 2-75), the page buffer cannot be flushed until it is verified that
the “before-image” of the page has already been written to disk. If this cannot
be verified, the physical log buffer must be flushed first, before the single
shared-memory page buffer is flushed. (Refer to page 2-74 for more infor-
mation about how this sequence of events is enforced.)
Buffer-pool flushing is initiated under any one of four conditions:
■ A requirement for page cleaning, determined by the value of
LRU_MAX_DIRTY (refer to page 2-58)
■ A need to flush a full logical log buffer or physical log buffer (refer to
page 2-63 and page 2-66, respectively)
■ A need to flush the logical log buffer after a committed transaction in
an unbuffered database (refer to page 2-66)
■ A need to execute a checkpoint (refer to page 2-70)