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 may 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.