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:
When the rollforward utility is invoked:
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. Authorities Required to Use RollforwardPrivileges 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. Using RollforwardYou 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:
The rollforward utility can be invoked through the command line processor (CLP), the database Rollforward Wizard in the Control Center, or the db2Rollforward API. Rollforward Database: ExamplesThe 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) |