Database Server Processes That Require Logging

As Dynamic Server operates, processing transactions, tracking data storage, and ensuring data consistency, Dynamic Server 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 needs to roll back a transaction, to execute 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 needed during a data restore, or until the administrator decides that the records are no longer needed for a restore. See Logical Log for more information on 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 on the format of logical-log records, see the chapter on interpreting logical-log records in the IBM 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 Details of Fast Recovery After A Full Checkpoint.)
• Data restoration. The database server uses the most recent storage-space and logical-log backups to re-create 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 IBM 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 on table inheritance, see the IBM Informix Database Design and Implementation Guide. For information on primary key and foreign key constraints, see the IBM 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.
• High-Availability Data Replication (HDR). High-Availability Data Replication uses logical-log records to maintain consistent data on two different 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 HDR 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 IBM Informix Dynamic Server Enterprise Replication Guide.