DB2 Version 9.7 for Linux, UNIX, and Windows

Rollforward recovery

To use the rollforward recovery method, you must have taken a backup of the database and archived the logs (by setting the logarchmeth1 and logarchmeth2 configuration parameters to a value other than OFF). Restoring the database and specifying the WITHOUT ROLLING FORWARD option is equivalent to using the version recovery method. The database is restored to a state identical to the one at the time that the offline backup image was made. If you restore the database and do not specify the WITHOUT ROLLING FORWARD option for the restore database operation, the database will be in rollforward pending state at the end of the restore operation. This allows rollforward recovery to take place.
Note: The WITHOUT ROLLING FORWARD option cannot be used if:
  • You are restoring from an online backup image
  • You are issuing a table space-level restore

The two types of rollforward recovery to consider are:

Table space rollforward recovery can be used in the following two situations:

Figure 2. Table Space Rollforward Recovery. There can be more than one active log in the case of a long-running transaction.
This graphic illustrates that there can be more than one active log in the case of a long-running transaction.

In a partitioned database environment, if you are rolling a table space forward to a point in time, you do not have to supply the list of database partitions on which the table space resides. DB2® submits the rollforward request to all database partitions. This means the table space must be restored on all database partitions on which the table space resides.

In a partitioned database environment, if you are rolling a table space forward to the end of the logs, you must supply the list of database partitions if you do not want to roll the table space forward on all database partitions. If you want to roll all table spaces (on all database partitions) that are in rollforward pending state forward to the end of the logs, you do not have to supply the list of database partitions. By default, the database rollforward request is sent to all database partitions.

If you are rolling a table space forward that contains any piece of a partitioned table and you are rolling it forward to a point in time, you must also roll all of the other table spaces in which that table resides forward to the same point in time. However, you can roll a single table space containing a piece of a partitioned table forward to the end of logs.
Note: If a partitioned table has any attached, detached, or dropped data partitions, then point-in-time rollforward must also include all table spaces for these data partitions. To determine if a partitioned table has any attached, detached, or dropped data partitions, query the SYSDATAPARTITIONS catalog table.