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.