The database server uses the shared-memory logical-log buffer as temporary storage for records that describe modifications to database server pages. From the logical-log buffer, these records of changes are written to the current logical-log file on disk and eventually to the logical-log backup media. For a description of logical logging, refer to Logical Log.
Five events cause the current logical-log buffer to flush:
The following sections discuss each of these events in detail.
When a user thread needs to write records to the logical-log buffer, it acquires the mutexes associated with the logical-log buffer and the current logical log on disk. If another thread is writing to the buffer, the incoming thread must wait for the mutexes to be released.
After the incoming thread acquires the mutexes, but before the write, the thread checks how much logical-log space is available on disk. When the logical-log space on disk is full, and the database server switches to a new logical log, it checks if the percent of used log space is greater than the long-transaction high-water mark, specified by the LTXHWM parameter in the ONCONFIG file. For a description of this configuration parameter and information on specifying a value for it, refer to the IBM Informix: Administrator's Reference.
If no long-transaction condition exists, the logical-log I/O thread compares the available space in the logical-log buffer with the size of the record to be written. If the write does not fill the logical-log buffer, the thread writes the record, releases latches, and awakens any threads that are waiting to write to the buffer.
If the write fills the logical-log buffer, flushing is initiated as follows:
If a transaction is prepared or terminated in a database with unbuffered logging, the logical-log buffer is immediately flushed. Flushing might cause a waste of some disk space. Typically, many logical-log records are stored on a single page. However, because the logical-log buffer is flushed in whole pages, the whole page is flushed even if only one transaction record is stored on the page. In the worst case, a single COMMIT logical-log record (COMMIT WORK) could occupy a page on disk, and all remaining space on the page would be unused. However, the cost in disk space of using unbuffered logging is minor compared to the benefits of insured data consistency.
The following log records cause flushing of the logical-log buffers in a database with unbuffered logging:
For a comparison of buffered versus unbuffered logging, refer to the SET LOG statement in the IBM Informix: Guide to SQL Syntax.
Even for nonlogging databases, the database server logs certain activities that alter the database schema, such as the creation of tables or extents. When the database server terminates sessions that use unbuffered logging or nonlogging databases, the logical-log buffer is flushed to make sure that any logging activity is recorded.
For a detailed description of the events that occur during a checkpoint, refer to Checkpoints.
When a page is modified that does not require a before-image in the physical log, the logical-log buffer must be flushed before that page is flushed to disk.
Blobpages are allocated and tracked with the free-map page. Links that connect the blobpages and pointers to the next blobpage segments are created as needed.
A record of the operation (insert, update, or delete) is written to the logical-log buffer.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]