logarchmeth2 - Secondary log archive method configuration parameter

This parameter specifies the media type of the secondary destination for logs that are archived from either the current log path or the mirror log path.

Configuration type

Database

Applies to

Database servers with local and remote clients
Clients
Database servers with local clients
Partitioned database servers with local and remote clients

Parameter type

Configurable online.¹ ²

Default [range]

OFF [DISK, DB2REMOTE, TSM, VENDOR]

OFF

Specifies that the log archiving method is not used. If you set both logarchmeth2 and logarchmeth2 configuration parameters to OFF, the database is considered to be using circular logging and is not rollforward recoverable. This is the default.

DISK

You must follow this value with a colon (:) and then a fully qualified existing path name where the log files will be archived. For example, if you set the logarchmeth2 configuration parameter to DISK:/u/dbuser/archived_logs the archive log files are placed in the /u/dbuser/archived_logs/instance/dbname/nodename/chainid/ directory.

Note: If you are archiving to tape, you can use the db2tapemgr utility to store and retrieve log files.

Note: If you are archiving to NFS, it is recommended to mount the NFS system with the nolock option.

DB2REMOTE

Specifies that remote storage, such as IBM Cloud Object Storage or Amazon Simple Storage Service (S3), is used to archive the log files. You must follow this value with a colon (:) and specify a remote storage location by using a storage access alias. The syntax for specifying a remote storage location is DB2REMOTE://<alias>/<container>/<object>. For more information, see Remote storage requirements.

Note: The DB2REMOTE option is available in Db2 11.5.7 or later.

TSM

If specified without any additional configuration parameters, indicates that log files are archived on the local IBM® Storage Protect server by using the default management class. If you follow this option with a colon (:) and a IBM Storage Protect management class, the log files are archived using the specified management class.

Note: IBM Storage Protect is the new product name for Tivoli Storage Manager (TSM).

The product now known as IBM Storage Protect was named IBM Spectrum Protect in levels earlier than 8.1.19. To learn more about the brand change, see IBM Spectrum Protect brand change to IBM Storage Protect.
The product previously known as IBM Spectrum Protect™ was named IBM Tivoli® Storage Manager in releases earlier than Version 7.1.3. To learn more about the rebranding transition, see Tivoli Storage Manager branding transition to IBM Spectrum Protect™.
IBM Spectrum Protect and IBM Tivoli Storage Manager 7.1 reached end of support (EOS) at 31 December 2021, see: IBM Spectrum Protect and Tivoli Storage Manager 7.1 products End of Support 31 December 2021.

When archiving logs using IBM Storage Protect, before using the management class that is specified by the database configuration parameter, IBM Storage Protect attempts to bind the object to the management class that you specified in the INCLUDE-EXCLUDE list in the IBM Storage Protect client options file. If a match is not found, the default IBM Storage Protect management class that you specified on the IBM Storage Protect server is used. IBM Storage Protect then rebinds the object to the management class that you specified for the database configuration parameter. Thus, the default management class and the management class that you specify for the database configuration parameter must contain an archive copy group, or the archive operation fails.

VENDOR

Specifies that a vendor library is used to archive the log files. You must follow this value with a colon (:) and the name of the library. The APIs in the library must use the backup and restore APIs for vendor products.

Notes:

Log archiving is complete only when both the logarchmeth1 method and the logarchmeth2 method have run successfully.
If you set either the logarchmeth1 or logarchmeth2 configuration parameter to a value other than OFF, the database is configured for rollforward recovery.
If you use the userexit or logretain option for the logarchmeth1 configuration parameter, you must set the logarchmeth2 configuration parameter to OFF.
The archive log path must not contain log files that do not belong to the current database. If the archive log path was previously used for a database of the same name, these log files must be removed before using the current archive log path.

If you use the logarchmeth2 configuration parameter to specify a path, log files will be archived to both this destination and the destination that is specified by the logarchmeth1 database configuration parameter. Which log files the logarchmeth2 configuration parameter archives depends on whether you also set the value of the mirrorlogpath database configuration parameter:

If you do not set the value of the mirrorlogpath configuration parameter, the logarchmeth2 configuration parameter archives log files from the current log path, as specified by the logpath configuration parameter.
If you set the value of the mirrorlogpath configuration parameter, the logarchmeth2 configuration parameter archives log files from the mirror log path.

¹ If logarchmeth1 is OFF, changing logarchmeth2 from OFF to a value other than OFF will only take effect after the database is reactivated, and an offline backup must be taken before the database can be reactivated.

² If logarchmeth1 is OFF, changing logarchmeth2 from a value other than OFF to OFF will only take effect after the database is reactivated.