Re: ** impact of time clock changes on Running Oracle DB
- From: "Mark J. Bobak" <mark@xxxxxxxxx>
- To: mgogala@xxxxxxxxxxxxxxxxxxxx
- Date: Fri, 25 Feb 2005 02:29:42 -0500
On Thu, 2005-02-24 at 16:09, Mladen Gogala wrote:
> A Joshi wrote:
>
> >Hi,
> > I would like to know the impact of changing the time on my UNIX machine.
> > how would it impact a ORACLE database running on the server. I think Oracle
> > takes its sysdate from the UNIX. Thanks for your help.
> >
> >
> You should have received a big sand watch with your Oracle CD set. Ask
> Oracle to send you the Redmond sand watch.
> Oracle customer support will love you for that. If you don't have the
> sand watch, then the only place that Oracle can get
> information about time is Unix. Changing time will, of course, create
> things that are not well ordered with respect to time,
> but nothing will be badly damaged because Oracle, as opposed to DB2,
> does not use seconds and/or microseconds for
> primary keys. If you are using DATE/TIMESTAMP column as a primary/unique
> key, you may have some trouble with
> your applications. That is precisely the reason why Einstein decided
> that time travel was forbidden by the laws of physics.
> Another thing that may be suffering is auditing. Once you travel into
> the past, you cannot be sure about the timing in any of
> auditing records. Normally time is being changed on weekends when there
> isn't much of any activity, so the time change has
> virtually no impact. If you are worried about the DST, the clock will
> be moving in harmless direction this time. It is the change
> in October that can cause problems. Time is changed on twice every year
> and nothing bad has ever happened to my
> databases.
I can think of one other (rare) scenario where it could cause confusion.
IF you adjust the server time,
AND the adjustment goes backwards in time,
AND then your database suffers a media failure before the next backup,
AND the recovery entails rolling forward to a point in time where time
stamps
overlap due to the time reset,
THEN you need to be careful, cause if (for example) at 1:30pm you reset
the
time to 1:15pm, then if you need to roll forward to some time between
1:15p and
1:30p, which one are you rolling forward to? The answer is to determine
the SCN
that corresponds to the point in time to which you wish to roll forward,
and do
an SCN based recovery rather than a time based recovery.
How many times has this happened to me? Exactly zero. Do I know
someone who
had to deal w/ it? Yes, a friend of mine was responsible for recovering
a database to
a point-in-time which happened to be the morning that we switched from
EDT to EST.
(Spring forward, fall back. This was in the Fall. Note that there is
no problem in
the Spring when time jumps forward.)
It's rare, but it can happen, and you should be aware of it and how to
work around it,
to avoid panic and confusion. ;-)
-Mark
--
Mark J. Bobak
mark@xxxxxxxxx
"Science is the belief in the ignorance of experts." --Richard P.
Feynman
--
//www.freelists.org/webpage/oracle-l
Other related posts:
