This parameter specifies if there is a limit to the percentage of the primary log space that a transaction can consume, and what that limit is.
If the value is not 0, this parameter indicates the percentage of primary log space that can be consumed by one transaction.
If the value is set to 0, there is no limit to the percentage of total primary log space that a transaction can consume.
If an application violates the max_log configuration, the application is forced to disconnect from the database and the transaction is rolled back.
You can override this behavior by setting the DB2_FORCE_APP_ON_MAX_LOG registry variable to "FALSE". This will cause transactions that violate the max_log configuration to fail; however, the application can still commit the work completed by previous statements in the unit or work, or it can roll the completed work back to undo the unit of work.
This parameter, along with the num_log_span configuration parameter, can be useful when enabling infinite active logspace. If infinite logging is on (that is, if logsecond is set to -1) then transactions are not restricted to the upper limit of the number of log files (logprimary + logsecond). When the value of logprimary is reached, DB2 starts to archive the active logs, rather than failing the transaction. This can cause problems if, for example, an application contains a long running transaction that is left uncommitted. If this occurs, the active logspace continues to grow, possibly leading to poor crash recovery performance. To prevent this, you can specify values for one or both of the max_log or num_log_span configuration parameters.