Performance considerations

When the logical-log files fill, you must 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 HCL OneDB™ Backup and Restore Guide.)

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 might 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.