For a given level of system activity, the less logical-log disk space that you allocate, the sooner that logical-log space fills up, and the greater the likelihood that user activity is blocked due to backups and checkpoints. Tune the logical-log size to find the optimum value for your system.
When the logical-log files fill, you have to back them up. The backup process can hinder transaction processing that involves data located on the same disk as the logical-log files. Put the physical log, logical logs, and user data on separate disks. (See the IBM Informix Backup and Restore Guide.)
Checkpoints block user processing briefly. If log files are backed up and freed more frequently, the checkpoints occur more frequently.
A smaller logical log fills faster than a larger logical log. You can add a larger logical-log file, as explained in Adding Logical-Log Files Manually.
The sizes of the logical-log records vary, depending on both the processing operation and the database server environment. In general, the longer the data rows, the larger the logical-log records. The logical log contains images of rows that have been inserted, updated, or deleted. Updates can use up to twice as much space as inserts and deletes because they might contain both before-images and after-images. (Inserts store only the after-image and deletes store only the before-image.)
The more logical-log records written to the logical log, the faster it fills. Databases with transaction logging fill the logical log faster than transactions against databases without transaction logging.
Databases that use unbuffered transaction logging fill the logical log faster than databases that use buffered transaction logging.
Because Enterprise Replication generates before-images and after-images of the replicated tables, it could cause the logical log to fill.
More rollbacks fill the logical log faster. The rollbacks themselves require logical-log file space although the rollback records are small.
Smart large objects that have user data logging enabled and have a large volume of user data updates can fill logical logs at a prodigious rate. Use temporary smart large objects if you do not want to log the metadata.