Database server processes that require logging

As HCL Informix® operates, processing transactions, tracking data storage, and ensuring data consistency, Informix® automatically generates logical-log records for some of the actions that it takes. Most of the time the database server makes no further use of the logical-log records. However, when the database server is required to roll back a transaction, to run a fast recovery after a system failure, for example, the logical-log records are critical. The logical-log records are at the heart of the data-recovery mechanisms.

The database server stores the logical-log records in a logical log. The logical log is made up of logical-log files that the database server manages on disk until they have been safely transferred offline (backed up). The database server administrator keeps the backed up logical-log files until they are required during a data restore, or until the administrator decides that the records are no longer required for a restore. See Logical log for more information about logical logs.

The logical-log records themselves are variable length. This arrangement increases the number of logical-log records that can be written to a page in the logical-log buffer. However, the database server often flushes the logical-log buffer before the page is full. For more information about the format of logical-log records, see the topics about interpreting logical-log records in the Informix® Administrator's Reference.

The database server uses logical-log records when it performs various functions that recover data and ensure data consistency, as follows:
Transaction rollback
If a database is using transaction logging and a transaction must be rolled back, the database server uses the logical-log records to reverse the changes made during the transaction. For more information, see Transaction logging.
Fast recovery
If the database server shuts down in an uncontrolled manner, the database server uses the logical-log records to recover all transactions that occurred since the oldest update not yet flushed to disk and to roll back any uncommitted transactions. (When all the data in shared memory and on disk are the same, they are physically consistent.) The database server uses the logical-log records in fast recovery when it returns the entire database server to a state of logical consistency up to the point of the most recent logical-log record. (For more information, see Fast recovery after a checkpoint.)
Data restoration
The database server uses the most recent storage-space and logical-log backups to recreate the database server system up to the point of the most recently backed-up logical-log record. The logical restore applies all the log records since the last storage-space backup.
Deferred checking
If a transaction uses the SET CONSTRAINTS statement to set checking to DEFERRED, the database server does not check the constraints until the transaction is committed. If a constraint error occurs while the transaction is being committed, the database server uses logical-log records to roll back the transaction. For more information, see SET Database Object Mode in the Informix® Guide to SQL: Syntax.
Cascading deletes
Cascading deletes on referential constraints use logical-log records to ensure that a transaction can be rolled back if a parent row is deleted and the system fails before the children rows are deleted. For information about table inheritance, see the Informix® Database Design and Implementation Guide. For information about primary key and foreign key constraints, see the Informix® Guide to SQL: Tutorial.
Distributed transactions
Each database server involved in a distributed transaction keeps logical-log records of the transaction. This process ensures data integrity and consistency, even if a failure occurs on one of the database servers that is performing the transaction. For more information, see Two-phase commit and logical-log records.
Data Replication
Data Replication environments that use HDR secondary, SD secondary, and RS secondary servers use logical-log records to maintain consistent data on the primary and secondary database servers so that one of the database servers can be used quickly as a backup database server if the other fails. For more details, see How data replication works.
Enterprise Replication
You must use database logging with Enterprise Replication because it replicates the data from the logical-log records. For more information, see the HCL® Informix® Enterprise Replication Guide.