Log management

When log archiving is configured for the database, rollforward recovery is possible. This is because of the following reasons:

• The logs record changes to the database during and after the backups are taken.
• Log files are kept even after they contain committed and externalized data referred to as “inactive” logs.

To configure log archiving, change the logarchmeth1 database parameter from OFF to an appropriate value by selecting the archiving mode required. The possible values for mode are:

LOGRETAIN

In this mode, inactive log files are never overwritten. This means that inactive logs must be moved to an archive location to avoid running out of disk space for primary logs. The database configuration specifies the number of active primary log files and active secondary log files that can be created. When LOGRETAIN is set, DB2® will first fill up the primary logs, and then if the first primary log is still active, DB2 will create secondary logs.If the number of primary and secondary logs have been created and filled has reached the maximum limit before the first primary log becomes inactive, a “log full” condition will occur. As primary logs become inactive, DB2 will create additional primary logs as needed.In the LOGRETAIN mode, it is important to monitor the disk space available for the log files because if the disk fills up, directory updates will not be possible until the condition is rectified.

USEREXIT

In this mode, archival and retrieval of logs is performed by a user-supplied user exit program called db2uext2. The user exit program is called to copy a log file to an archive location as soon as the log file is full.This allows DB2 to rename and reuse the file once it becomes inactive.During recovery operations, after restoring a database from a backup, when inactive log files are required, DB2 will call the user exit program to retrieve the necessary logs from the archive location.

DISK:directory

With this setting, log management is performed using an algorithm similar to the USEREXIT mode. The difference between the two modes, USEREXIT and DISK:directory, is that instead of calling the user exit program, DB2 will automatically archive the logs from the active log directory to the specified directory. During recovery, DB2 retrieves these logs from that location.

TSM:[management class name]

This mode is similar to the USEREXIT mode except that logs will be automatically archived on the local Security Storage Manager server. The management class name parameter is optional. If not specified, the default management class is used.

VENDOR:library

In this mode, logging operates in a mode similar to USEREXIT except that the specified vendor library is invoked to archive or retrieve the logs.

When this parameter is configured, the database is enabled for rollforward recovery. After logarchmeth1 is set to for log archiving, a full offline backup of the database must be made for the “backup pending state” to be satisfied so that the database can be used. To check if the database is in “backup pending state”, look at the “Backup pending” value returned from the following DB2 command, which could either be YES or NO.

db2 get db config for ldapdb2

A recovery history file is created with each database and this file is updated automatically with summary information whenever you carry out a backup or restore of a full database or tablespace. The recovery history file is a useful tracking mechanism for restore activity within a database. This file is created in the same directory as the database configuration file. It is automatically updated whenever one of the following activities is performed:

• Backup of a database or tablespace
• Restore of a database or tablespace
• Rollforward of a database or tablespace
• Alter of a tablespace
• Quiesce of a tablespace
• Rename of a tablespace
• Load of a table
• Drop of a table
• Reorganization of a table
• Update of table statistics

For information about existing backed-up databases, enter the following DB2 command:

db2 list history backup all for db ldapdb2

The database configuration file contains the logarchmeth1 and other parameters related to rollforward recovery. In some cases, since the default parameter settings will not work well, you may need to change some of these default settings for your setup. See the DB2 Administration Guide for detailed information about configuring these parameters in DB2.

Primary logs (logprimary)

This parameter specifies the number of primary logs that might be active at a given time.

Secondary logs (logsecond)

This parameter specifies the number of secondary log files that might be created if all active primary logs are full.

Log size (logfilsiz)

This parameter determines the number of pages for each of the configured logs. A page is 4 KB in size.

Log buffer (logbufsz)

This parameter enables you to specify the amount of database shared memory to use as a buffer for log records before writing these records to disk.

Number of commits to group (mincommit)

This parameter enables you to delay the writing of log records to disk until a minimum number of commits have been performed.

New log path (newlogpath)

You can change the location where active logs and future archive logs are placed by changing the value for this configuration parameter to point to either a different directory or a device.

Primary log archive method (logarchmeth1)

This parameter specifies the media type of the primary destination for archived logs. See section “Log management” for details about the options available.

Secondary log archive method (logarchmeth2)

This parameter specifies the media type of the secondary destination for archived logs.If this parameter is specified, log files will be archived using both this method and the method specified by logarchmeth1.

Track modified pages (trackmod)

When this parameter is set to "Yes", the database manager tracks database modifications so that the backup utility can detect which subsets of the database pages must be examined by an incremental backup and potentially included in the backup image. After setting this parameter to "Yes", you must take a full database backup in order to have a baseline against which incremental backups can be taken.