As the Informix database server operates--as it processes transactions, keeps track of data storage, ensures data consistency, and so on--it 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 offline logical-log records (in 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. For more information, see Logical Log.
The database server uses logical-log records when it performs various functions that recover data and ensure data consistency, as follows:
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.
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 the second phase of 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.)
During a data restore, you use the logical-log backup with the most-recent storage-space backup to re-create the database server system up to the point of the most recently backed-up logical-log record. After restoring the storage spaces, the database server restores the logical logs to reimplement all the logged activity since the last storage-space backup.
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 from the transaction to roll back the transaction. For more information, see SET Database Object Mode in the IBM Informix: Guide to SQL Syntax.
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.