Log control files

When a database restarts after a failure, the database manager applies transaction information stored in log files to return the database to a consistent state. To determine which records from the log files need to be applied to the database, the database manager uses information recorded in log control files.

Redundancy for database resilience

The database manager maintains two copies of the each member's log control file, SQLOGCTL.LFH.1 and SQLOGCTL.LFH.2, and two copies of the global log control file, SQLOGCTL.GLFH.1 and SQLOGCTL.GLFH.2, so that if one copy is damaged, the database manager can still use the other copy.

Performance considerations

Applying the transaction information contained in the log control files contributes to the overhead of restarting a database after a failure. You can configure the frequency at which the database manager writes buffer pool pages to disk in order to reduce the number of log records that need to be processed during crash recovery using the page_age_trgt_mcr - Page age target member crash recovery configuration parameter .

Configure the ctrl_file_recov_path for additional redundancy

Starting in version 11.5.7, it is possible to specify a redundancy path where a copy of critical control files (including these log control files) is maintained, which may aid recovery in the event that the control files are inadvertently deleted, corrupted, or no longer accessible within the database path. For more information, refer to ctrl_file_recov_path - Database control file recovery path configuration parameter.