Subject:  What are the effects of changing the system clock on an Oracle Server instance? 
Creation Date:  18-NOV-1999 
 

PURPOSE

  Part of the Oracle Server Year 2000 FAQ series

RELATED DOCUMENTS 

  [NOTE:69388.1]  Y2K FAQ - Server Products


For the most part, Oracle is oblivious to the system clock setting since its 
internal timing uses System Commit Numbers (SCNs) and system clock ticks, 
instead of time stamps and the system time. As a result, we can say that 
changing the system clock should really have no effect on the Oracle kernel 
since Oracle's internal timing mechanisms do not make use of the system time. 
Rather, Oracle relies on system clock ticks for internal timing. System clock
ticks are generally defined as the number of milliseconds since the operating
system was last booted. However, the implementation details are platform 
specific.

Although the Oracle instance does not rely on the system time, certain 
facilities such as replication, incremental exports, PL/SQL jobs, and 
point-in-time recovery are subject to the system time. These utilities can 
adjust to jumping forward in time, in situations like daylight savings and 
minor system clock adjustments. The same can be said of Y2K testing procedures
where the system date continually advances (i.e. October 1999, then November 
1999, then December 1999, etc ...).

The problems arise when moving the system clock backwards in time. In 
particular, time-based media recovery can be hampered in this situation. More 
specifically, there may be problems if you use RECOVER DATABASE UNTIL TIME if
time has changed between the time you recover and the time the backup is taken.

Consider the following:

       3pm       4pm     4.30    5pm-->4pm     4.16pm  4.30   5pm
        |---------|-------|-------|-----|-------|-------|--------|
        cold/hot  T1      T2      T3   clock    T4      T5      T6
        backup                         change

If you wish to recover to the T5, you will not be able to since Oracle will 
recover to the first occurrence of 4:30 which is T2. In Oracle7 and Oracle8 
you can recover to a specific SCN (RECOVER ... UNTIL CHANGE) which is system
clock independent, but when using RECOVER ... UNTIL TIME will not give the 
desired results.

The best course of action is to take a full backup prior to making large leaps
forward in system time that you eventually plan on setting back. Understand 
that any redo logs generated with the system clock set to a future date will be
timestamped with that future date. This timestamp in the redo log sequence will
negate your ability to make use of the time-based recovery mechanism after you
set your system clock back and until your next full backup. However, you would 
still be able to rely on SCN based recovery and CANCEL based recovery after 
such a flip-flop. 

As for the operating system, it unlikely that any major changes to the OS would
be required after moving backwards through time. Even cron jobs should not be 
affected since they would simply re-fire when the time criteria are met. 
However, do realize that backup mechanisms you have in place may be triggered 
by system clock change.

In brief, changing the system clock for reasons other than daylight savings and
normal adjustments should be restricted to test systems and strongly discouraged
on production systems. The factors that lie outside the Oracle instance are too
numerous to make any other generalization. However, if you do not plan to ever 
make use of time-based recovery, then there should be no adverse effects to 
your Oracle installation.