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.
- Inactive log files that have not been archived yet (and not moved to failarchpath).
- Retrieve log files (if overflowlogpath parameter is not set).
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.
- 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
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.
- 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) 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.