log_disk_cap - Active log space disk capacity configuration parameter

This parameter allows you to specify the maximum disk capacity for storing transaction log records in the active log path.

Such a concept used to be represented by (logprimary + logsecond) * logfilsiz configuration parameters, but could only cover the logging of all inflight transactions. In addition to the logging consumption by inflight transactions, the log_disk_cap parameter also covers all usages of space in the active log path, for example:
  • Inactive log files that have not been archived yet (and not moved to failarchpath).
  • Retrieve log files (if overflowlogpath parameter is not set).
  • Extraction log files if Advanced Log Space Management is enabled.

If log_disk_cap is configured, the logprimary and logsecond configuration parameters will be used as guidance on the consumption for inflight transactions. However, the number of files created on disk for logging of inflight transactions might be adjusted based on other consumption. The logfilsiz configuration parameter is still used to specify the size of the active log files.

It is expected that there is sufficient disk space available in the active log path to support the amount set by this configuration. If mirrorlogpath configuration parameter is set, it is also expected there is sufficient disk space available in the mirror log path to support the amount set by this configuration.

In pureScale environment, a single file system is used for the active log paths of all members. The log_disk_cap configuration limits the disk usage by a single member. Therefore, it is expected that sufficient disk space is available in the file system to support the usage by all members, ie. log_disk_cap * number_of_members.

In DPF environment, it is recommended that a separate file system is used for the logging of each partition. If the database is configured to use a single file system for the logging of multiple partitions, it is expected that sufficient disk space is available in the file system to support the usage by all partitions.

Note that a successful database activation requires available disk space for all primary log files. If log_disk_cap is configured, a successful database activation will require at least enough available disk space for two log files.

Configuration type
Database
Parameter type
Configurable
Default [range]
0 [-1 - 2147483647]

0 means this parameter is not in use; the current configured log space is used.
-1 means there is no limit on usage, so whatever the file system can support.

Unit of measure
MB
Note: This parameter has limited support starting from Db2® version 11.5.4. It is only utilized when infinite logging is enabled (logsecond = -1). In all other configurations setting log_disk_cap to a nonzero value has no effect.

Recommendation: Sufficient disk space is required in order to support the workload (i.e. the inflight changes made by all the connections to the database), in order to avoid applications getting SQL0964N error.

If log_disk_cap is configured to a value lower than the current disk space consumption of all log related files on disk, the requested value will still be accepted but will not come into effect until the log disk space consumption lowers to below the requested log_disk_cap value.

In addition, it is strongly recommended to set failarchpath database configuration parameter to provide additional disk space to hold log files that could not be archived. This ensures all the configured disk space can be used to support the workload.

In addition, it is strongly recommended to set overflowlogpath database configuration parameter to provide additional disk space to hold log files retrieved from archive. The following are some of the reasons to retrieve log files (when there could be a workload running on the database):
  • the use of db2ReadLog() API (e.g by replication products such as Q Replication or CDC Replication) might need to read from a log file that is no longer found in active log path
  • an online tablespace ROLLFORWARD operation might need to retrieve log files from archive
  • an online BACKUP operation might need to retrieve log files in order to include them in the backup image
  • HADR primary might need to retrieve log files to support remote catchup when the standby database falls behind

If using infinite logging (logsecond = -1), it may be possible that log archiving is slow or the archive log path is in an error state. When this is the case, the active log files cannot be archived and removed from the active log paths in a timely fashion. In such a situation, Db2 may have written to all the configured (logprimary) log files, in which case Db2 will not create active log files above the configured limit. When this happens, applications may notice a lag in performance until log archiving catches up or any error is resolved. This behavior will be experienced when log_disk_cap is set to the default value of 0. To avoid such a performance behavior consider setting log_disk_cap to some non-0 value and Db2 will create additional log files above the configured limit up to the value specified by log_disk_cap (-1 is no limit so Db2 will attempt to use the physical limit of the file system the active log paths are on). Over time, the number of log files will be reduced back to the configured amount as the demand for additional log space subsides.

If using infinite logging (logsecond = -1) and Advanced Log Space Management is enabled, it may be possible that the extraction scan is slow or is being idled due to a throttle reason, such as extraction ratio. If so, an active log file may need to be reused for new log data before it can be extracted from. This can happen when the configured (logprimary) number of log files has been reached. In this case, required log data for inflight transactions may not be found locally and so for rollback or crash recovery a log file may need to be retrieved from the archives. To avoid this, set log_disk_cap to -1 or a large enough value so that additional active log files can be created.