Log file management through log archiving

Db2® server log file archiving is complicated by various operating-system file handling and scheduling problems. For example, if a disk fails as the Db2 database manager is archiving a queue of log files, those log files and the transaction data that they contain might be lost. Correctly configuring database logging can prevent these kinds of problems from undermining your availability and recovery strategy.
The following general considerations apply to all methods of log archiving:
  • The logarchcompr1 database configuration parameter specifies whether the database manager compresses log files that are contained in the location specified by logarchmeth1. If the logarchmeth1 configuration parameter to a value other than DISK, TSM, or VENDOR, log archive compression has no effect regardless of the logarchcompr1 configuration parameter setting.
  • The logarchcompr2 database configuration parameter specifies whether the database manager compresses log files that are contained in the location specified by logarchmeth2. If the logarchmeth2 configuration parameter to a value other than DISK, TSM, or VENDOR, log archive compression has no effect regardless of the logarchcompr2 configuration parameter setting.
  • The logarchmeth1 database configuration parameter causes the database manager to archive log files or to retrieve log files during rollforward recovery of databases by using the method that you specify. A request to retrieve a log file is made when the rollforward utility needs a log file that is not found in the log path directory. Log files are archived from the path that is specified by the logpath configuration parameter.

    The logarchmeth2 database configuration parameter causes the database manager to archive additional copies of log files. If you configure mirror logging, the log files that are archived to the path that is specified by the logarchmeth2 parameter are taken from the mirror log path. If you do not configure mirror logging, the log files that are archived to the path that is specified by the logarchmeth2 parameter are taken from the current log path.

  • You should not use locally attached tape drives to store log files if you are using any of the following features:
    • Infinite logging
    • Online recovery at the table space level
    • Replication
    • db2ReadLog API
    • High availability disaster recovery (HADR)
    Any of these features can cause a log file to be retrieved, which can conflict with log archiving operations. Also, you cannot use locally attached tape drives in a Db2 pureScale® environment because the member that is performing the log merge operation must retrieve logs for the other members.
  • If you are using log archiving, the log manager attempts to archive active logs as they are filled. In some cases, if a database is deactivated before the log manager can record the archive as successful, the log manager might try to archive the log again when the database is activated. Thus, a log file can be archived more than once.
  • If you use archiving, a log file is passed to the log manager when it is full, even if the log file is still active and is needed for normal processing. This process allows copies of the data to be moved away from volatile media as quickly as possible. The log file that is passed to the log manager is retained in the log path directory until it is no longer needed for normal processing. At this point, the disk space is reused.
  • If a log file is archived and contains no open transactions, the Db2 database manager does not delete the file but renames it as the next log file when such a file is needed. This process improves performance because creating a new log file instead of renaming the file would require all pages to be written out to guarantee that the necessary disk space or other storage space is available. The database manager retains up to 8 extra log files in the active log path for renaming purposes.
  • During crash recovery, during member crash recovery (in a Db2 pureScale environment), or during runtime rollback, the Db2 database manager does not retrieve log files unless you set the logsecond database configuration parameter to -1 (that is, if you enable infinite logging). In a Db2 pureScale environment, the database manager might have to retrieve archived logs during a group crash recovery even if you do not enable infinite logging.
  • By default, retrieved log files are placed under a subdirectory in the active log path. However, if an overflow log path is configured instead, the retrieved log files are placed in that configured overflow log path.
  • Configuring log archiving does not guarantee rollforward recovery to the point of failure but only attempts to make the failure window smaller. As log files are filled, the log manager asynchronously archives the logs. If the disk that contains the log fails before a log file is filled, the data in that log file is lost. Also, because the files are queued for archiving, the disk can fail before all the files are copied, causing any log files in the queue to be lost.

    To help prevent the case where a failure of the disk or device on which the log path is located causes log files to be permanently lost, you can use the mirrorlogpath database configuration parameter to ensure that the logs are written to a secondary path. If the secondary path does not fail along with the primary disk or device, the log files are available for recovery.

    When you set both the mirrorlogpath and logarchmeth2 configuration parameters, the logarchmeth2 configuration parameter archives log files from the mirror log path instead of archiving additional copies of the log files in the current log path. You can use this log archiving behavior to improve resilience during rollforward recovery. The reason is that a usable archived log file from the mirror log path might still be available to continue a database recovery operation, even if a primary log file from the current log path became corrupted because of a disk failure before archiving.

  • The configured size of each log file has a direct bearing on log archiving. If each log file is very large, a large amount of data can be lost if a disk fails. If you configure your database to use small log files, the log manager archives the logs more frequently.

    However, if you are moving the data to a slower device such as tape, you might want to have larger log files to prevent the queue from building up. Using larger log files is also recommended if archiving each file requires substantial overhead, such as rewinding the tape device or establishing a connection to the archive media.

  • If you use log archiving, the log manager attempts to archive primary logs as they are filled. In some cases, the log manager archives a log before it is full. This occurs if the log file is truncated because the database is deactivated, you issue the ARCHIVE LOG command, the end of an online backup is reached, or you issue the SET WRITE SUSPEND command.
    Note: To free unused log space, a log file is truncated before it is archived.
  • If you are archiving logs and backup images to a tape drive, you must ensure that the same tape drive is not the destination for both the backup images and the archived logs. Because some log archiving can take place while a backup operation is in progress, an error can occur when the two processes are trying to write to the same tape drive at the same time.
The following considerations apply to calling a user exit program or a vendor program for archiving and retrieving log files:
  • The Db2 database manager opens a log file in read mode when it starts a user exit program to archive the file. On some operating systems, this prevents the user exit program from being able to delete the log file. Other operating systems, such as the AIX® operating system, allow processes, including the user exit program, to delete log files. A user exit program should never delete a log file after it is archived, because the file might still be active and needed for crash recovery. The Db2 database manager manages disk space reuse when it archives the log files.
  • A user exit or vendor program might receive a request to archive a file that does not exist, because there were multiple requests to archive and the file was deleted after the first successful archiving operation. A user exit or vendor program might also receive a request to retrieve a file that does not exist, because it is located in another directory or the end of the logs was reached. In both cases, the user exit or vendor program should ignore this request and pass a successful return code.
  • On Windows operating systems, you cannot use a REXX user exit to archive logs.
  • The user exit or vendor program should allow for the existence of different log files with the same name after a point-in-time recovery. The user exit or vendor program should be written to preserve both log files and to associate those log files with the correct recovery path.
  • If you enable a user exit or vendor program for two or more databases that are using the same tape device to archive log files and a rollforward operation is taking place on one of the databases, no other database should be active. If another database tries to archive a log file while the rollforward operation is in progress, one of the following situations might occur:
    • The logs that are required for the rollforward operation might not be found.
    • The new log file that is archived to the tape device might overwrite the log files that were previously stored on that tape device.
    To prevent either situation from occurring, you can take one of the following steps:
    • You can ensure that no other databases on the database partition that calls the user exit program are open during the rollforward operation.
    • You can write a user exit program to handle this situation.