Log file management

Consider the following when managing database logs:

• The numbering scheme for archived logs starts with S0000000.LOG, and continues through S9999999.LOG, accommodating a potential maximum of 10 million log files. The database manager resets to S0000000.LOG if:
  • A database configuration file is changed to enable rollforward recovery
  • A database configuration file is changed to disable rollforward recovery
  • S9999999.LOG has been used.

  The DB2 database manager reuses log file names after restoring a database (with or without rollforward recovery). The database manager ensures that an incorrect log is not applied during rollforward recovery. If the DB2 database manager reuses a log file name after a restore operation, the new log files are archived to separate directories so that multiple log files with the same name can be archived. The location of the log files is recorded in the recovery history file so that they can be applied during rollforward recovery. You must ensure that the correct logs are available for rollforward recovery.

  When a rollforward operation completes successfully, the last log that was used is truncated, and logging begins with the next sequential log. Any log in the log path directory with a sequence number greater than the last log used for rollforward recovery is reused. Any entries in the truncated log following the truncation point are overwritten with zeros. Ensure that you make a copy of the logs before invoking the rollforward utility. (You can invoke a user exit program to copy the logs to another location.)

• If a database has not been activated (by way of the ACTIVATE DATABASE command), the DB2 database manager truncates the current log file when all applications have disconnected from the database. The next time an application connects to the database, the DB2 database manager starts logging to a new log file. If many small log files are being produced on your system, you might want to consider using the ACTIVATE DATABASE command. This not only saves the overhead of having to initialize the database when applications connect, it also saves the overhead of having to allocate a large log file, truncate it, and then allocate a new large log file.
• An archived log can be associated with two or more different log sequences for a database, because log file names are reused (see Figure 1). For example, if you want to recover Backup 2, there are two possible log sequences that could be used. If, during full database recovery, you roll forward to a point in time and stop before reaching the end of the logs, you have created a new log sequence. The two log sequences cannot be combined. If you have an online backup image that spans the first log sequence, you must use this log sequence to complete rollforward recovery.

  If you have created a new log sequence after recovery, any table space backup images on the old log sequence are invalid. This is usually recognized at restore time, but the restore utility fails to recognize a table space backup image on an old log sequence if a database restore operation is immediately followed by the table space restore operation. Until the database is actually rolled forward, the log sequence that is to be used is unknown. If the table space is on an old log sequence, it must be "caught" by the table space rollforward operation. A restore operation using an invalid backup image might complete successfully, but the table space rollforward operation for that table space will fail, and the table space will be left in restore pending state.

  For example, suppose that a table space-level backup operation, Backup 3, completes between S0000013.LOG and S0000014.LOG in top log sequence (see Figure 1). If you want to restore and roll forward using the database-level backup image, Backup 2, you need to roll forward through S0000012.LOG. After this, you could continue to roll forward through either the log sequence from which you took Backup 3 or the newer log sequence. If you roll forward through the newer log sequence, you cannot use the table space-level backup image, Backup 3, to perform table space restore and rollforward recovery.

  To complete a table space rollforward operation to the end of the logs using the table space-level backup image, Backup 3, you have to restore the database-level backup image, Backup 2, and then roll forward using the top log sequence. After the table space-level backup image, Backup 3, has been restored, you can initiate a rollforward operation to the end of the logs.

Figure 1. Reusing log file names