Log file allocation and removal

A log file which is required for crash recovery is called an active log. Unless infinite logging is enabled, log files in the active log path are never removed if they might be required for crash recovery.

If infinite logging is enabled and space needs to be made available for more active log files, the database manager archives an active log file and renames it to create a new active log file. If crash recovery is needed when infinite logging is used, log files might need to be retrieved from the archive log path to complete crash recovery. When you enable infinite logging, if the database manager is able to archive files successfully, then there is no limit to the number of active log files that can be created. However, if the database manager is not able to archive files successfully, then there is a limit to the number of unarchived active logs. This limit is based on the upper limit of logprimary. If this limit is reached, the database manager will allocate additional log files as long as there is disk space available in the file system.

When the logarchmeth1 database configuration parameter is not set to OFF, a full log file becomes a candidate for removal only after it is no longer required for crash recovery, unless infinite logging is enabled, in which case the log files might be moved to the archive log path instead.

When logarchmeth1 or logarchmeth2 is set to a value other than OFF, LOGRETAIN, or USEREXIT, archived log file compression can be enabled to help reduce the amount of disk space required for archived log files.

The process of allocating new log files and removing old log files is dependent on the settings of the logarchmeth1 and logarchmeth2 database configuration parameters:

logarchmeth1 and logarchmeth2 are set to OFF

Circular logging is used. Roll-forward recovery is not supported with circular logging, while crash recovery is.

During circular logging, new log files, other than secondary logs, are not generated and old log files are not deleted. Log files are handled in a circular fashion. That is, when the last log file is full, the database manager begins writing to the first log file.

A log full situation can occur if all of the log files are active and the circular logging process cannot wrap to the first log file. Secondary log files are created when all the active log files are active and full. Secondary log files are deleted when the database is deactivated or when the space they are using is required for the primary log files.

logarchmeth1 or logarchmeth2 is set to LOGRETAIN

Archive logging is used. The database is a recoverable database. Both roll-forward recovery and crash recovery are enabled. The database manager does not manage the log files. After you archive the log files, you must delete them from the active log path so that the disk space can be reused for new log files. To determine which log files are archived logs, check the value of the loghead database configuration parameter. This parameter indicates the lowest numbered log that is active. Those logs with sequence numbers less than the loghead value are not active and can be archived and removed.

logarchmeth1 or logarchmeth2 is set to a value other than OFF or LOGRETAIN

Archive logging is used. The database is a recoverable database. Both roll-forward recovery and crash recovery are enabled. When a log file becomes full, it is automatically archived by the database manager.

Log files are not deleted. Instead, when a new log file is required and one is not available, an archived log file is renamed and used again. An archived log file, is not deleted or renamed once it is closed and copied to the archived log file directory. The database manager renames the oldest archived log when it is no longer needed for crash recovery. A log file that is moved to the database directory during recovery is removed during the recovery process when it is no longer needed.

If an error occurs when log files are being archived, archiving is suspended for the amount of time specified by the archretrydelay database configuration parameter. You can also use the numarchretry database configuration parameter to specify the number of times that the database manager is to try archiving a log file to the primary or secondary archive directory before it tries to archive log files to the failover directory (specified by the failarchpath database configuration parameter). Numarchretry is only used if the failarchpath database configuration parameter is set. If numarchretry is set to 0, the database manager continuously tries archiving from the active or the mirror log path.

The easiest way to remove old log files is to restart the database. Once the database is restarted, only new log files and log files that the database manager failed to archive are found in the database directory.

When a database is restarted, the minimum number of logs in the database log directory equals the number of primary logs which can be configured using the logprimary database configuration parameter. It is possible for more than the number of primary logs to be found in the log directory. This condition occurs if the number of empty logs in the log directory at the time the database was shut down, is greater than the value of the logprimary configuration parameter at the time the database is restarted. This happens if the value of the logprimary configuration parameter is changed between the database being shut down and restarted, or if secondary logs are allocated and never used.

When a database is restarted, if the number of empty logs is less than the number of primary logs specified by the logprimary configuration parameter, additional log files are allocated to make up the difference. If there are more empty logs than primary logs available in the database directory, the database can be restarted with as many available empty logs as are found in the database directory. After database shutdown, secondary log files that are created remain in the active log path when the database is restarted.