Because a checkpoint logically empties the physical log when it becomes 75 percent full, it is unlikely that the log would become 100 percent full before the checkpoint completes. To assure further that the physical log does not become full during a checkpoint, take the following actions:
Fuzzy checkpoints keep the physical log from filling up too quickly when applications are doing intensive updates. (See Fuzzy Checkpoint.) However, the physical log could still become full, as the following sections describe.
Under normal processing, once a checkpoint is requested, and the checkpoint begins, all threads are prevented from entering critical sections of code. (See Critical Sections.) However, threads currently in critical sections can continue processing. The physical log can become full if many threads in critical sections are processing work and if the space that remains in the physical log is very small. The many writes that are performed as threads complete their critical section processing could conceivably cause the physical log to become full.
Fuzzy checkpoints keep the physical log from filling up too quickly when applications are doing intensive updates. You can reduce the size of the physical log when applications require less intensive updates or when updates tend to cluster within the same pages. You can decrease the size of the physical log if you intend to use physical-log fullness to trigger checkpoints.
If you increase the checkpoint interval or anticipate increased activity, consider increasing the size of the physical log. For more information, see the chapter on effects of configuration on I/O activity in your IBM Informix: Performance Guide.
The physical log can overflow if you use simple large objects in a nonlogging table. Consider the following example about simple large objects in dbspaces stored in a logging table.
When the database server processes these simple large objects, each portion of the simple large object that the database server stores on disk can be logged separately, allowing the thread to exit the critical sections of code between each portion. However, if logging is turned off, the database server must carry out all operations on the simple large object in one critical section. If the simple large object is large, and the physical log small, this scenario can cause the physical log to become full. If this situation occurs, the database server sends the following message to the message log:
Physical log file overflow
The database server then initiates a shutdown. For the suggested corrective action, refer to this message in your message log.
This same unlikely scenario could occur during the rollback of a long transaction after the second long-transaction high-water mark, LTXEHWM, is reached. (See Logical Log and Long Transactions.) After the LTXEHWM is reached, and after all threads have exited critical sections, only the thread that is performing the rollback has access to the physical and logical logs. However, the writes that are performed as threads complete their processing could conceivably fill the physical log during the rollback if the following conditions occur simultaneously: