DB2 10.5 for Linux, UNIX, and Windows

Database rollforward operations in a DB2 pureScale environment

In a DB2® pureScale® environment, each member has its own log stream; however, log streams from all members are required for successful execution of the ROLLFORWARD DATABASE command.

During a database rollforward operation, log records from all of the log streams are merged and replayed to make the database consistent. The point in time that you specify on the ROLLFORWARD DATABASE command is relative to the merged log stream. To restore the database to a consistent state, the specified time must be later than the minimum recovery time (MRT). The MRT is the earliest time during a rollforward operation when objects that are listed in the database catalog match the objects that physically exist on disk. For example, if you are restoring from an image that was created during an online backup operation, the specified point in time for the rollforward operation must be later than the time at which the online backup operation completed. This will ensure database consistency.

The specified point in time for the subsequent database rollforward operation must be greater than or equal to the MRT in the merged log stream; otherwise, the rollforward operation fails (SQL1276N), and the timestamp of the MRT is returned with the error message. Alternatively, you can use the END OF BACKUP option to automatically roll forward to the MRT.

It is recommended that the member clocks be synchronized; however, it might not be possible to synchronize them at all times. This can result in log records having the same time stamp, and merged log streams with log records that appear to be out of time stamp order. In a DB2 pureScale environment, a point-in-time database rollforward operation stops when it encounters the first log record whose time stamp is greater than the specified time stamp from any log stream, and it has processed the log record that corresponds to the MRT for the database.

An incomplete or interrupted rollforward operation leaves the database in rollforward pending state. In this case, issue another ROLLFORWARD DATABASE command. In a DB2 pureScale environment, subsequent ROLLFORWARD DATABASE commands can be run on the same or on a different member.

In a DB2 pureScale environment, if you want to perform a database restore operation into a new database using an online database backup image, the correct approach depends on whether all of the log files are available, or only log files from the backup image are available.

If pre-existing log files or archived log files can be accessed, the following rollforward operation is appropriate:
```
   db2 rollforward db dbname to end of logs and stop
```
Note: Before taking a backup, you need to ensure that the log archiving path is set to a shared directory so that all the members are able to access the logs for subsequent rollforward operations. If the archive path is not accessible from the member on which the rollforward is being executed, SQL1273N is returned. The following command is an example of how to set the log path to the shared directory:
```
db2 update db cfg using logarchmeth1 
      DISK:/db2fs/gpfs1/svtdbm5/svtdbm5/ArchiveLOGS 
```
(where gpfs1 is the shared directory for the members and ArchiveLOGS is the actual directory that archives the logs.
If the only log files that can be accessed come from the backup image, the following rollforward operation is appropriate:
```
   db2 rollforward db dbname to end of backup and stop
```
This command replays all required log records to achieve the consistent database state that was in effect when the backup operation ended. You can also use this command if pre-existing log files or archived log files can be accessed, but it will stop at the point at which the backup operation ended; it will not use any extra logs that were generated after the backup operation ended.
A ROLLFORWARD DATABASE command specifying the END OF LOGS option in this case would return SQL1273N. A subsequent ROLLFORWARD DATABASE command with the STOP option is successful, and the database will be available, if the missing log files are not needed. However, if the missing log files are needed (and it is not safe to stop), the rollforward operation will again return SQL1273N.

Example

Suppose that there are two members, M1 and M2. M2's clock is ahead of M1's clock by five seconds. M2's log stream contains the following log records:

A1 at 2010-04-03-14.21.56
A2 at 2010-04-03-14.21.56
B at 2010-04-03-14.21.58
C at 2010-04-03-14.22.01

M1's log stream contains the following log records:

D at 2010-04-03-14.21.55
E at 2010-04-03-14.21.56
F at 2010-04-03-14.21.57

The minimum recovery time (MRT) for the database on M2 is at time 2010-04-03-14.21.55. Because M1's clock is five seconds slow, log records D, E, and F appear later in the merged log stream:

MRT: 2010-04-03-14.21.55 (M2)
A1:  2010-04-03-14.21.56 (M2)
A2:  2010-04-03-14.21.56 (M2)
B:   2010-04-03-14.21.58 (M2)
D:   2010-04-03-14.21.55 (M1) --> corresponding time on M2 is 14.22.00
C:   2010-04-03-14.22.01 (M2)
E:   2010-04-03-14.21.56 (M1) --> corresponding time on M2 is 14.22.01
F:   2010-04-03-14.21.57 (M1) --> corresponding time on M2 is 14.22.02

The alphabetic characters (A1, A2, B, and so on) represent the order in which the corresponding log records were actually written at run time (across members). Note that log records A1 and A2 from member M2 have the same time stamp; this can happen when the DB2 data server tries to optimize performance by including the commit log record from multiple transactions when data is written from the log buffer to a log file.

The following command returns SQL1276N (Database "test" cannot be brought out of rollforward pending state until rollforward has passed a point in time greater than or equal to "2010-04-03-14.21.55"):

db2 rollforward db test to 2010-04-03-14.21.54

But the following command rolls forward the database up to and including log record A2:

db2 rollforward db test to 2010-04-03-14.21.56

Because log records A1 and A2 both have a time stamp that is less than or equal to the time that was specified in the command, both are replayed. Log record B, whose time stamp (2010-04-03-14.21.58) is greater than the specified value (2010-04-03-14.21.56), stops the rollforward operation and is not replayed. Log record D is not replayed either, even though its time stamp is less than the specified value, because log record B's higher value (2010-04-03-14.21.58) was encountered first. The following command rolls forward the database up to and including log record D:

db2 rollforward db test to 2010-04-03-14.21.58

Log record C, whose time stamp (2010-04-03-14.22.01) is greater than the specified value (2010-04-03-14.21.58), stops the rollforward operation and is not replayed. Log record E is not replayed either, even though its time stamp is less than the specified value.