IBM Books

Administration Guide

Recovery Method: Roll-Forward Recovery

Roll-forward recovery using the BACKUP command in conjunction with the RESTORE and ROLLFORWARD commands puts the database or table space in a state that has been previously saved.

When you first create a database, only circular logging is enabled for it. This means that logs are re-used (in a circular fashion), and are not saved or archived. With circular logging, roll-forward recovery is not possible: only crash recovery or version recovery is enabled. When log archiving is performed, however, roll-forward recovery is possible, because the logs record changes to the database after the time that the backup was taken. You perform log archiving by activating either (or both) of the logretain and userexit database configuration parameters. When either of these parameters are enabled, the database is enabled for roll-forward recovery.

When the database is recoverable, you can perform backup, restore, and roll-forward recovery at both the database and the table space level. The backups of the database and table space can be online. Online restore and rollforward are also available at the table space level.

Roll-forward recovery re-applies the completed units of work recorded in the logs to the restored database, table space, or table spaces. You can specify that roll-forward recovery is to the end of the logs, or to a particular point in time.

Roll-forward recovery can follow the completion of a full database restore as described in "Restoring a Database". It can also be done with table spaces that are in a roll-forward pending state. For considerations on rolling forward a table space, see "Rolling Forward Changes in a Table Space"

For more information about the database configuration parameters associated with logging, see "Configuration Parameters for Database Logging".

Backup Considerations

Following are the backup considerations that apply when your database is enabled for forward recovery. For general information that applies to performing backups, refer to the following:

The recovery history file is updated automatically with summary information whenever you carry out a backup or restore of a full database or table space. This file can be a useful tracking mechanism for restore activity within a database. This file is created in the same directory as the database configuration file. For more information on the recovery history file, see "Recovery History File Information".

In UNIX-based environments, the file name(s) created on disk will consist of a concatenation of the following information, separated by periods; on other platforms a four-level subdirectory tree is used:

Database alias
A 1-to-8 character database alias name that was supplied when the backup command was invoked.

Type of backup taken, where: "0" is for full database, "3" is for table space, and "4" is for copy from a table load.

Instance name
A 1-to-8 character name of the current instance of the database manager that is taken from the DB2INSTANCE environment variable.

Node number
The node number.

Catalog node number
The node number of the database's catalog node.

Time stamp
A 14-character representation of the date and time the backup was performed. The timestamp is in the format yyyymmddhhnnss, where:
   yyyy is the year (1995 to 9999)
   mm is the month (01 to 12)
   dd is the day of the month (01 to 31)
   hh is the hour (00 to 23)
   nn is the minutes (00 to 59)
   ss is the seconds (00 to 59)

Sequence number
A 3-digit sequence number used as a file extension.

Restore Considerations

Following are the restore considerations that apply when your database is enabled for forward recovery. For general information that applies to performing restores, refer to the following:

Rolling Forward Changes in a Database

Roll-forward recovery builds on a restored database and allows you to restore a database to a particular time that is after the time that the database backup was taken. This point can be either the end of the logs, or a point between the time of the database backup and the end of the logs.

You might use point-in-time recovery if an active or an archived log is not available. In this situation, you could roll forward to the point where the log is missing. You might also roll forward to a point in time if a bad transaction was run against the database. In this situation, you would restore the database, then roll forward to just before the time that the bad transaction was run.

Figure 31. Roll-Forward Recovery


You can also perform point-in-time roll-forward recovery on table spaces. For additional information, see "Rolling Forward Changes in a Table Space".

To use this method, the database must be configured to enable roll-forward recovery. Considerations for the database configuration file and database logs are presented in the following topics:

If you have tables that contain DATALINK columns, also see "Restoring Databases and Table Spaces and Rolling Forward to the End of the Logs" and "Restoring Databases and Table Spaces and Rolling Forward to a Point in Time".

Configuration Parameters for Database Logging

The database configuration file contains parameters related to roll-forward recovery. The default parameters do not support this recovery, so if you plan to use it, you need to change some of these defaults. For additional information, see Chapter 20. "Configuring DB2".

Primary logs (logprimary)
This parameter specifies the number of primary logs that will be created.

A primary log, whether empty or full, requires the same amount of disk space. Thus, if you configure more logs than you need, you use disk space unnecessarily. If you configure too few logs, you can encounter a log-full condition. As you select the number of logs to configure, you must consider the size you make each log and whether your application can handle a log-full condition.

If you are enabling an existing database for roll-forward recovery, change the number of primary logs to the sum of the number of primary and secondary logs, plus 1. Additional information is logged for long varchar and LOB fields in a database enabled for roll-forward recovery.

Secondary logs (logsecond)
This parameter specifies the number of secondary log files that are created and used for recovery log files (only as needed).

When the primary log files become full, the secondary log files (of size logfilsiz) are allocated one at a time as needed, up to a maximum number as controlled by this parameter. An error code will be returned to the application, and activity against the database will be stopped, if more secondary log files are required than are allowed by this parameter.

See "Number of Secondary Log Files (logsecond)" for recommendations on how to use secondary logs.

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

The size of each primary log has a direct bearing on performance. When the database is configured to retain logs, each time a log is filled, a request is issued for allocation and initialization of a new log. Increasing the size of the log reduces the number of requests required to allocate and initialize new logs. (Keep in mind, however, that with a larger log size it takes more time to format each new log). The formatting of new logs is transparent to applications connected to the database so that database performance is unaffected by formatting.

Assuming that you have an application that keeps the database open to minimize the processing time to open a database (see "Recovery Performance Considerations"), the value for the log size should be determined by the amount of time it takes to make offline archived log copies.

The data transfer speed of the device you use to store offline archived logs, and the software used to make the copies, must at a minimum match the average rate at which the database manager writes data in the logs. If the transfer speed cannot keep up with new log data being generated, you may run out of disk space if logging activity continues for a sufficiently long period of time, determined by the amount of free disk space. If this happens, database processing will stop.

The data transfer speed is most significant when using tape or some optical medium. (Refer to Appendix L. "User Exit for Database Recovery" for information on using different media for storing logs.) Some tape devices require the same amount of time to copy a file, regardless of its size. You must determine the capability of your archiving device.

Additionally, tape devices have some unique considerations. The frequency of the archiving request is important. If the time for any copy operation is five minutes, the log size should be large enough to hold five minutes of log data during your peak work load. Also, the tape device may have design limits that restrict the number of operations per day. These factors must be considered when you determine the log size.

Minimizing log file loss is also an important consideration in setting the log size. Archiving takes an entire log. If you use a single large log, you increase the time between archiving. If the medium containing the log fails, some transaction information will probably be lost. Decreasing the log size increases the frequency of archiving but can reduce the amount of information loss in case of a media failure since the smaller logs before the one lost can be used.

Log Buffer (logbufsz)
This parameter allows you to specify the amount of database shared memory to use as a buffer for log records before writing these records to disk. The log records are written to disk when one of the following occurs:

Buffering the log records will result in more efficient logging file I/O, because the log records will be written to disk less frequently and more log records will be written at each time.

Number of Commits to Group (mincommit)
This parameter allows you to delay the writing of log records to disk until a minimum number of commits have been performed. This delay can help reduce the database manager overhead associated with writing log records and, as a result, improve performance when you have multiple applications running against a database and many commits are requested by the applications within a very short time frame.

This grouping of commits will only occur when the value of this parameter is greater than 1, and when the number of applications connected to the database is greater than the value of this parameter. When commit grouping is being performed, application commit requests are held until the earlier of either one second elapsing or the number of commit requests equals the value of this parameter.

New log path (newlogpath)
The database logs are initially created in SQLOGDIR, which is a subdirectory of the database directory. 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 to a device. Archive logs that are currently stored in the database log path directory are not moved to the new location if the database is configured for roll-forward recovery.

Because you can change the log path location, the logs needed for roll-forward recovery may exist in different directories or on different devices. You can change this configuration parameter during the roll-forward process to allow you to access logs in multiple locations.

The change to the value of newlogpath will not be applied until the database is in a consistent state. A database configuration parameter indicates the status of the database. See "Database is Consistent (database_consistent)" for additional information about this status indicator. See "Considerations for Managing Log Files" for information about the roles database logs play if a database is not in a consistent state.

Log retain (logretain)
This parameter causes archived logs to be kept in the database log path directory. Enabling it allows the database manager to use the roll-forward recovery method. You do not require userexit to be enabled when the logretain configuration parameter is enabled. Either one of the two parameters is sufficient to allow the roll-forward recovery method.

Using this parameter means that the circular logging, that is the default, is being overridden.

User exit (userexit)
This parameter causes the database manager to call a user exit program for archiving and retrieving logs. With the user exit enabled, roll-forward recovery is allowed. You do not require logretain to be enabled when the userexit configuration parameter is enabled. Either one of the two parameters is sufficient to allow the roll-forward recovery method.

Using this parameter means that the circular logging, that is the default, is being overridden. Userexit implies logretain but the reverse is not true.

See Appendix L. "User Exit for Database Recovery", for information about the user exit program.

The active log path is important when using either the userexit configuration parameter or the logretain configuration parameter to allow roll-forward recovery. When the userexit configuration parameter is set, the user exit is called to archive log files away from the active log path. When the logretain configuration parameter is set, this ensures that the log files remain in the active log path. The active log path is determined either by the Path to Log Files or Changed Path to Log Files (newlogpath).

Rolling Forward Changes in a Table Space

If the database is enabled for forward recovery, you have the option of backing up, restoring, and rolling forward table spaces instead of using the entire database. You may want to implement a recovery strategy for individual table spaces because this can save time: it takes less time to recover a portion of the database than it does to recover the entire database. For example, if a disk is bad and it only contains one table space, the table space can be restored and rolled forward without having to recover the entire database (and without impacting user access to the rest of the database). Also, table-space-level backups allow you to back up critical portions of the database more frequently than other portions, which requires less time than backing up the entire database.

If, in a partitioned database environment, some database partitions are in the roll-forward pending state, and, on other database partitions, some table spaces are in the roll-forward pending state (but the database partition is not), you must first roll forward the database partitions, then roll forward the table spaces.

If the data and long objects of a table are in separate table spaces, and the table has been reorganized, the table spaces for both the data and long objects must be restored and rolled forward together. You should take a back up of the affected table spaces after the table is reorganized.

Different states are associated with a table space to indicate its current status:

After a table space is restored, it is always in the roll-forward pending state (that is, if you restore a table space and specify the WITHOUT ROLLING FORWARD parameter, the WITHOUT ROLLING FORWARD is ignored). To make the table space usable, you must perform roll-forward recovery on it. You have the option of rolling forward to the end of the logs, or rolling forward to a point in time. If you want to roll forward a table space to a point in time, you should be aware of the following:

If you cannot find back up image of TABSP1 that is after time T3, or you want to restore TABSP1 to T3 or before, you can:

In a partitioned database environment you must roll forward all portions of the table space to the same point in time at the same time. This ensures that the table space is consistent across database partitions.

Planning to Use the ROLLFORWARD Command

Before using the ROLLFORWARD command you should consider the following items:

Note:You cannot use ROLLFORWARD CANCEL to cancel a roll-forward operation that is running. You can only use it to cancel a roll-forward operation that completed but did not have ROLLFORWARD STOP issued for it, or for a roll-forward operation that failed before completing.

If you have tables that contain DATALINK columns, also see "Restore and Rollforward Utility Considerations".

Invoking the ROLLFORWARD Command

There are a number of considerations before invoking the ROLLFORWARD command:

Using the Load Copy Location File

The DB2LOADREC environment variable is used to identify the file with the load copy location information. This file is used during roll-forward recovery to locate the load copy. It has information on:

If the location file does not exist or no matching entry is found in the file, the information from the log record is used.

The information in the file may be overwritten before the roll-forward recovery takes place.


  1. In a partitioned database environment, the DB2LOADREC environment variable must be in the db2profile file.

  2. In a partitioned database environment, the load copy file must exist at each database partition server, and the file name (including the path) must be the same.

The following information is provided in the location file. The first five parameters must have valid values and are used to identify the load copy. The entire structure is repeated for each load copy recorded. For example:

TIMestamp      19950725182542         * Timestamp generated at load time
SCHema         PAYROLL                * Schema of table loaded
TABlename      EMPLOYEES              * Table name
DATabasename   DBT                    * Database name
DB2instance    TORONTO                * DB2INSTANCE
BUFfernumber   NULL                   * Number of buffers to be used for recovery
SESsionnumber  NULL                   * Number of sessions to be used for recovery
TYPeofmedia    L                      * Type of media - L for local device
                                                        A for ADSM
                                                        O for other vendors
LOCationnumber 3                      * Number of locations
   ENTry       /u/toronto/dbt.payroll.employes.001
   ENT         /u/toronto/dbt.payroll.employes.002
   ENT         /dev/rmt0
TIM            19950725192054
SCH            PAYROLL
TAB            DEPT
DAT            DBT
DB2            TORONTO
SES            NULL
BUF            NULL
TYP            A
TIM            19940325192054
SCH            PAYROLL
TAB            DEPT
DAT            DBT
DB2            TORONTO
SES            NULL
BUF            NULL
TYP            O
SHRlib         /@sys/lib/backup_vendor.a


Note:If you run LOAD COPY NO and do not take a backup copy of the database or affected table spaces after running LOAD, you cannot restore the database or table spaces to a point in time after the LOAD was performed. That is, you cannot use roll-forward recovery to rebuild the database or table spaces to a state after the LOAD. You can only restore the database or table spaces to a point in time that precedes the LOAD.

If you want to use a particular load copy, the LOAD timestamps are recorded in the recovery history file for the database. In a partitioned database environment, the recovery history file is local to each database partition.

For more information on LOAD, see "Using the LOAD Utility".

Considerations for Managing Log Files

There are items to be considered when managing database logs:

Losing Logs

You may encounter a situation similar to the following: You would like to do a point-in-time recovery on a full database but you are concerned that you might lose a log during the recovery process. (This scenario could occur if you have an extended number of archived logs between the time of the last backup database image and the point-in-time where you would like to have the database recovered.)

First, you should copy all of the applicable logs to a "safe" location. Then you can run the RESTORE command and use the roll-forward recovery method to the point-in-time you wish for the database. If any of the logs that you need is damaged or lost during this process, you have a backup copy of all of the logs elsewhere.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]