DB2 10.5 for Linux, UNIX, and Windows

logsecond - Number of secondary log files configuration parameter

This parameter specifies the number of secondary log files that are created and used for recovery log files. The secondary log files are created only as needed.

Configuration type
Database
Parameter type
Configurable Online
Propagation class
Immediate
Default [range]
10 [-1; 0 - 254 ]
Note: The default value is subject to change by the DB2® Configuration Advisor after initial database creation.
Unit of measure
Counter
When allocated
As needed when logprimary is insufficient. For more allocation details, see the details that follow.
When freed
Over time as the database manager determines which secondary log files are no longer needed.

When the primary log files become full, the secondary log files (of size logfilsiz) are allocated one at a time as needed, up to a maximum number as controlled by this parameter. If more secondary log files are required than are allowed by this parameter, an error code will be returned to the application.

If you set logsecond to -1, the database is configured with infinite active log space. There is no limit on the size or the number of in-flight transactions running on the database. If you set logsecond to -1, you still use the logprimary and logfilsiz configuration parameters to specify how many log files the database manager should keep in the active log path. If the database manager needs to read log data from a log file, but the file is not in the active log path, the database manager retrieves the log file from the archive to the active log path. (The database manager retrieves the files to the overflow log path, if you have configured one.) Once the log file is retrieved, the database manager will cache this file in the active log path so that other reads of log data from the same file will be fast. The database manager will manage the retrieval, caching, and removal of these log files as required.
Note: You cannot configure infinite active log space in DB2 pureScale® environments.

If your log path is a raw device, you must configure the overflowlogpath configuration parameter in order to set logsecond to -1.

By setting logsecond to -1, you will have no limit on the size of the unit of work or the number of concurrent units of work. However, rollback (both at the savepoint level and at the unit of work level) could be very slow due to the need to retrieve log files from the archive. Crash recovery could also be very slow for the same reason. The database manager writes a message to the administration notification log to warn you that the current set of active units of work has exceeded the primary log files. This is an indication that rollback or crash recovery could be extremely slow.

To set logsecond to -1, the logarchmeth1 configuration parameter must be set to a value other than OFF or LOGRETAIN.

Recommendation: Use secondary log files for databases that have periodic needs for large amounts of log space. For example, an application that is run once a month might require log space beyond that provided by the primary log files. Because secondary log files do not require permanent file space, they are advantageous in this type of situation.

When infinite logging is enabled (logsecond to -1), the database manager does not reserve active log space for transactions that might need to roll back and write log records. During rollback processing, if both the active log path and archive target are full (or if the archive target is inaccessible), then the blk_log_dsk_ful (block on log disk full db configuration parameter) should also be ENABLED to avoid database failures.