You should maintain relatively synchronized system clocks across the database partition servers to ensure smooth database operations and unlimited forward recoverability. The time difference among the database partition servers plus any potential operational and communication delays for a transaction should be less than the value found in the Maximum Time Difference Among Nodes (max_time_diff) database manager configuration parameter.
To ensure that the log record timestamps reflect the sequence of transactions, DB2 in a partitioned database system uses the system clock on each machine as the basis for the timestamps in the log records. If, however, the system clock is set ahead, the log clock is automatically set ahead with it. Although the system clock can be set backwards, the clock for the logs cannot, and remains at the same advanced time until the system clock exceeds this time. At this time, the log time again reflects the system clock. The implication of this is that a short-term system clock error on a database node can have long-lasting effect on the timestamps of database logs.
As a hypothetical example, assume that the system clock on database partition server A is mistakenly set to November 7, 1999 when the year is 1997, and assume that the mistake is quickly corrected after an update transaction is committed in the database partition at that database partition server. If the database is in continual use, and is regularly updated over time, any point in time between November 7, 1997 and November 7, 1999 is virtually unreachable through roll-forward recovery. When the commit on database partition server A is done the timestamp in the database log is set to 1999, and the clock of the database log stays at November 7, 1999, until the system clock exceeds this time. If you attempt to roll forward to a point in time within the incorrect time frame, the operation will stop at the first timestamp that is beyond the specified stop point, which is November 7, 1997.
Although DB2 cannot control updates to the system clock, the max_time_diff database manager configuration parameter reduces the possibility of this type of problem occurring in the database system:
To correct and prevent an incorrect timestamp in a database log from being propagated further:
After you do these steps, the log time will be adjusted, the incorrect timestamp will not be propagated, and you will be able to do point-in-time recovery on the database partition from the last backup that you took of the partition.