This utility recovers a database by applying transactions recorded in the database log files. It is invoked after a database or table space backup has been restored. The database must be recoverable before the database can be recovered with rollforward recovery.
In a multi-partitioned database environment, the rollforward database command can be issued only from the catalog partition.
db2 rollforward db sample to end of logs Rollforward Status Input database alias = sample Number of nodes have returned status = 1 Node number = 0 Rollforward status = not pending Next log file to be read = Log files processed = S0000000.LOG - S0000001.LOG Last committed transaction = 2002-08-29-17.31.53.000000 DB20000I The ROLLFORWARD command completed successfully.
The general approach to rollforward recovery involves:
Invoking the rollforward utility without the STOP option.
Invoking the rollforward utility with the QUERY STATUS option.
If you specify recovery to the end of the logs, the QUERY STATUS option can indicate that one or more log files is missing, if the returned point in time is earlier than you expect.
If you specify point-in-time recovery, the QUERY STATUS option will help you to ensure that the rollforward operation has completed at the correct point.
Invoking the rollforward utility with the STOP option. After the operation stops, it is not possible to roll additional changes forward.
When the rollforward utility is invoked:
If the database is in rollforward pending state, the database is rolled forward. If table spaces are also in rollforward pending state, you must invoke the rollforward utility again after the database rollforward operation completes to roll the table spaces forward.
If the database is not in rollforward pending state but table spaces in the database are in rollforward pending state:
If you specify a list of table spaces, only those table spaces are rolled forward.
If you do not specify a list of table spaces, all table spaces that are in rollforward pending state are rolled forward.
A database rollforward operation runs offline. The database is not available for use until the rollforward operation completes successfully, and the operation cannot complete unless the STOP option was specified when the utility was invoked.
A table space rollforward operation can run offline. The database is not available for use until the rollforward operation completes successfully. This occurs if the end of the logs is reached or if the STOP option was specified when the utility was invoked.
You can perform an online rollforward operation on table spaces, as long as SYSCATSPACE is not included. When you perform an online rollforward operation on a table space, the table space is not available for use, but the other table spaces in the database are available.
When you first create a database, it is enabled for circular logging only. This means that logs are reused, rather than being saved or archived. With circular logging, rollforward recovery is not possible: Only crash recovery or version recovery can be done. Archived logs document changes to a database that occur after a backup was taken. You enable log archiving (and rollforward recovery) by setting the logretain database configuration parameter to RECOVERY or setting the userexit database configuration parameter to YES, or both. The default value for both of these parameters is NO, because initially, there is no backup image that you can use to recover the database. When you change the value of one or both of these parameters, the database is put into backup pending state, and you must take an offline backup of the database before it can be used again.
Privileges enable users to create or access database resources. Authority levels provide a method of grouping privileges and higher level database manager maintenance and utility operations. Together, these act to control access to the database manager and its database objects. Users can access only those objects for which they have the appropriate authorization, i.e., the required privilege or authority.
You must have SYSADM, SYSCTRL, or SYSMAINT authority to use the rollforward utility.
You should not be connected to the database that is to be rollforward recovered: The rollforward utility automatically establishes a connection to the specified database, and this connection is terminated at the completion of the rollforward operation.
Do not restore table spaces without canceling a rollforward operation that is in progress; otherwise, you may have a table space set in which some table spaces are in rollforward in-progress state and some table spaces are in rollforward pending state. A rollforward operation that is in progress will operate only on the table spaces that are in rollforward in-progress state.
The following restrictions apply to the rollforward utility:
You can invoke only one rollforward operation at a time. If there are many table spaces to recover, you can specify all of them in the same operation.
If you have renamed a table space following the most recent backup operation, ensure that you use the new name when rolling the table space forward. The previous table space name will not be recognized.
You cannot cancel a rollforward operation that is running. You can cancel only a rollforward operation that has completed but for which the STOP option has not been specified or a rollforward operation that has failed before completing.
You cannot continue a table space rollforward operation to a point in time, specifying a time stamp that is less than the previous one. If a point in time is not specified, the previous one is used. You can initiate a rollforward operation to a point in time by just specifying STOP, but this is allowed only if the table spaces involved were all restored from the same offline backup image. In this case, no log processing is required. If you start another rollforward operation with a different table space list before the in-progress rollforward operation is either completed or cancelled, an error message (SQL4908) is returned. Invoke the LIST TABLESPACES SHOW DETAIL or get snapshot for TABLESPACES command on all database partitions to determine which table spaces are currently being rolled forward (rollforward in-progress state) and which table spaces are ready to be rolled forward (rollforward pending state). You have three options:
Finish the in-progress rollforward operation on all table spaces.
Finish the in-progress rollforward operation on a subset of table spaces. This may not be possible if the rollforward operation is to continue to a specific point in time, which requires the participation of all database partitions.
Cancel the in-progress rollforward operation.
In a partitioned database environment, the rollforward utility must be invoked from the catalog partition of the database.
The rollforward utility can be invoked through the command line processor (CLP), the database Rollforward Wizard in the Control Center, or the db2Rollforward API.
The ROLLFORWARD DATABASE command permits specification of multiple operations at once, each being separated with the key word AND.
For example, to roll forward to the end of logs and complete, use the separate commands:
db2 rollforward db sample to end of logs db2 rollforward db sample complete
The above commands can be combined as follows:
db2 rollforward db sample to end of logs and complete
Although the two are equivalent, it is recommended that such operations be done in two steps. It is important to verify that the rollforward operation has progressed as expected before stopping it and possibly missing logs. This is especially important if a bad log is found during rollforward recovery, and the bad log is interpreted to mean the "end of logs." In such cases, an undamaged backup copy of that log could be used to continue the rollforward operation through more logs.
After restoring the database, roll forward to a point in time, using OVERFLOW LOG PATH to specify the directory where the user exit saves archived logs:
db2 "rollforward db sample to end of logs and stop overflow log path (/data/archlog)" Rollforward Status Input database alias = sample Number of nodes have returned status = 1 Node number = 0 Rollforward status = not pending Next log file to be read = Log files processed = S0000000.LOG - S0000000.LOG Last committed transaction = 2002-08-29-17.31.53.000000 DB20000I The ROLLFORWARD command completed successfully.
An example of rolling forward a table space (tscustomer) that resides on a single-partition database partition group (on database partition number 2):
db2 rollforward db dwtest to end of logs on dbpartitionnum (2) tablespace(tscustomer)