DB2 v6.1 on AIX 4.3.3
A couple of our unix boxes have been set up with the wrong time (a couple are also
correct). They present a DB2 Coordinated Universal Time. or CUT, which is ahead by 9
hours. The timezone is also incorrect, but we plan to change this environment setting
and we expect no impact on the operation of DB2. However, for the system time, we are
not so certain. We have an opportunity during a major outage this week, so we are
evaluating our options as a matter of urgency.
It seems the critical place of impact is roll forward recovery to a point in time
(specified in CUT). At this stage we have 2 options to change the time.
1. Change the system time and do not start DB2 for 9 hours, thus waiting until the
clock 'catches up' to CUT so that ther are no overlapping CUT times to confuse
recovery (if required). We expect that this is the safe option.
2. Change the system time and NOT wait for 9 hours. This means that DB2 will be in
operation over the same CUT for a period of up to 9 hours. Is this a problem? If we
need to recover and roll forward, either to a point in time or even to end of logs,
over this time period, should we expect it to work?
I dont know if there is any impact on the recovery history file, but we can avoid the
items listed in here, except for restore and roll forward (which we would like to
avoid, but cannot guarantee).
Is recovery the only thing in DB2 impacted by a change of the CUT?
BTW, we are also investigating if any applications have been using the SQL reserved
words (current timestamp etc) to determine any imapct on the stored data.
Has anybody done this before?
Thanks and Regards,
Bruce Allen
application/ms-tnef
