IBM 000-8697 User Manual

System Architecture

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

), 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

 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

■

A need to flush a full logical log buffer or physical log buffer (refer to

 and

, respectively)

■

A need to flush the logical log buffer after a committed transaction in
an unbuffered database (refer to

)

■

A need to execute a checkpoint (refer to