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:
- Database rollforward recovery. In this type
of rollforward recovery, transactions recorded in database logs are applied
following the database restore operation (see Figure 1). The
database logs record all changes made to the database. This method completes
the recovery of the database to its state at a particular point in time, or
to its state immediately before the failure (that is, to the end of the active
logs.)
In a partitioned database environment, the database is
located across many database partitions, and the ROLLFORWARD DATABASE command
must be issued on the database partition where the catalog tables for the
database resides (catalog partition). If you are performing point-in-time
rollforward recovery, all database partitions must be rolled forward to ensure
that all database partitions are at the same level. If you need to restore
a single database partition, you can perform rollforward recovery to the end
of the logs to bring it up to the same level as the other database partitions
in the database. Only recovery to the end of the logs can be used if one database
partition is being rolled forward. Point-in-time recovery applies to all database partitions.
Figure 1. Database Rollforward Recovery.
There can be more than one active
log in the case of a long-running transaction.
- Table space rollforward recovery. If the
database is enabled for forward recovery, it is also possible to back up,
restore, and roll table spaces forward (see Figure 2). To perform
a table space restore and rollforward operation, you need a backup image of
either the entire database (that is, all of the table spaces), or one or more
individual table spaces. You also need the log records that affect the table
spaces that are to be recovered. You can roll forward through the logs to
one of two points:
- The end of the logs; or,
- A particular point in time (called point-in-time recovery).
Table space rollforward recovery can be used in the following two situations:
- After a table space restore operation, the table space is always in rollforward
pending state, and it must be rolled forward. Invoke the ROLLFORWARD DATABASE
command to apply the logs against the table spaces to either a point in time,
or to the end of the logs.
- If one or more table spaces are in rollforward
pending state after crash recovery, first correct the table space problem.
In some cases, correcting the table space problem does not involve a restore
database operation. For example, a power loss could leave the table space
in rollforward pending state. A restore database operation is not required
in this case. Once the problem with the table space is corrected, you can
use the ROLLFORWARD DATABASE command to apply the logs against the table spaces
to the end of the logs. If the problem is corrected before crash recovery,
crash recovery might be sufficient to take the database to a consistent, usable
state.
Note: If the table space in error contains the system catalog
tables, you will not be able to start the database. You must restore the SYSCATSPACE
table space, then perform rollforward recovery to the end of the logs.
Figure 2. Table Space
Rollforward Recovery.
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.