Using an overflow log path
Configuring an overflow log path can help with the management of recovery log files when the retrieval of archived log files is required to facilitate a ROLLFORWARD recovery operation, or a db2ReadLog API request (used by replication products such as Q Replication or Change Data Capture), and other use cases. Without configuring the overflow log path, retrieved log files are placed under a subdirectory in the active log path. The basic behavior of the overflow log path is outlined in overflowlogpath - Overflow log path configuration parameter.
The overflow log path can be configured by using the OVERFLOWLOGPATH configuration parameter, or the OVERFLOW LOG PATH option of the ROLLFORWARD command.
If an overflow log path is configured, then log files that are retrieved from an archive log location are placed into the overflow log path. Otherwise, they are placed into the active log path. This is referred to as the log retrieve location.
Consider some of the benefits and behaviors of using an overflow log path:
Using an overflow log path can help isolate and secure the active log path:
By using an overflow log path, log files that are retrieved from the archive are placed into the overflow log path instead of a subdirectory under the active log path. This method can help to isolate the active log path from intrusion or accidental manipulation of live active log data. It can also prevent the active log path from unexpected disk/storage full conditions.
In high-performance environments, active log paths are often configured with the fastest (first-tier) storage/disk. By using an overflow log path in these environments, a database administrator can use second-tier storage if desired.
Using an overflow log path can assist with the preparation of a ROLLFORWARD:
When it is known beforehand that a ROLLFORWARD operation requires log files from an archive log path, a database administrator can manually retrieve these log files from the archive log path either before a ROLLFORWARD operation is started, or while it is running (if the ROLLFORWARD does not reach the replay log position contained in these log files). This method alleviates the need for ROLLFORWARD to retrieve log files from the archive log path in real time, and eliminates the possibility for failure during the ROLLFORWARD due to a transient retrieve log error or transient network issue.
Using an overflow log path can avoid the retrieval of archived log files:
If the archive log paths (LOGARCHMETH1, LOGARCHMETH2, or both) are configured to use DISK method, then the overflow log path can be configured to point to the exact location of the archive log path. In this configuration, ROLLFORWARD avoids copying log files from the archive log path to the retrieve location. When the overflow log path is configured in this way, Db2® reads the log files directly from the overflow log path (which is the archive log path), and saves the cost of unnecessary I/O copy operations. When you configure the overflow log path in this way (to point to the archive log path), it is configured to point to the chain subdir subpath of the archive log path. For example, if the archive log path (LOGARCHMETH1 or LOGARCHMETH2) is configured as DISK:/some_logarch_path/, then the overflow log path would be configured as /some_logarch_path/<instance name>/<db name>/.