Filter
Top Products
System Architecture 2-69
Logical Log Buffer
Note, however, that this cost of unbuffered logging is minor compared to the
benefits of ensured data consistency. (Refer to page 3-34 for further infor-
mation about the benefits of unbuffered logging compared to buffered
logging.)
Flushing a Full Buffer
When a user process needs to write a record to the logical log buffer, it
acquires the latch associated with the logical log buffer and the latch
associated with the current logical log on disk. If another user process is
writing to the buffer, the incoming user process must wait for the latches to
be released.
After the incoming user process acquires the latches, before the write, the
user process first checks how much logical log space is available on disk. If
the percentage of used log space is greater than the long transaction high-
water mark (specified by
LTXHWM), the user process wakes the tbinit
daemon to check for a long transaction condition. (Refer to page 2-158 for a
definition of a long transaction and its effect on the logical logs.)
If there is no long-transaction condition, the user process compares the
available space in the logical log buffer with the size of the record to be
written. If this write does not fill the logical log buffer, the record is written,
latches are released, and any user process waiting to write to the buffer is
awakened.
If this write fills the logical log buffer exactly, flushing is initiated as follows:
1. The user process latches the next logical log buffer. The user process
then switches the shared-memory current-buffer pointer, making the
newly latched buffer the current buffer.
2. The user process writes the new record to the new current buffer. The
latch on the logical log on disk and the latch on this new, current
buffer are released, permitting other user processes to begin writing
to the new current buffer.
3. The full logical logbuffer is flushed to disk and the latch on the buffer
is released. This logical log buffer is now available for reuse.