|
Oracle does keep track of time in v$timer
but its implementation eludes me. However, the implementation probably doesn’t
matter because of the manner in which ntpd (or xntpd) changes the system clock.
See RFC1305 for more information on what’s called the Fuzzball
Implementation. It basically states that ntpd will gradually adjust the system
clock until it ‘matches’ its master(s). When your host restarts you will probably
want to execute (in /etc/init.d/ntpd) ntpd with a –g argument so that it
will initially set the system clock to its master’s clock regardless of
how far its own clock has drifted. Then, from that point forward, ntpd will impose
only tiny adjustments. The reason I mention this is so that you
can feel more comfortable about measuring time in units larger than
milliseconds. If you wish to measure time in milliseconds or microseconds while
ntpd is changing the clock, then be prepared to get goofy data. The good news
is that you’re not likely to get more than one or two consecutive goofy data
points because ntpd can implement tiny adjustments very quickly. If ntpd were
constantly changing the clock then that would mess things up (but there would
be a bug fix on the web in no time short if it happened). The extremely good
news is that you probably don’t have an application that cares about short
time intervals (e.g., less than 5,000 microseconds). Sure, it’s possible
that Oracle might occasionally register a wait event that was slightly smaller
or larger (1cs) than reality but that would matter only if the number of wait
events were very small. When we perceive a wait event related performance
problem it’s either because the event lasted a long time (seconds) and/or
there were many of them. Why would you attack a single wait event that
registered as, say, 3cs instead of 2cs? Jeff Holt -----Original Message----- I am
considering ntpd to synchronize my server times but I wanted to check if there
are any issues with actively synchronizing the system time when there is an
oracle database involved. Does the db maintain its own time clock after
its started so that the timestamps in the control file are not affected by
outside adjustments? I am curious of what anyone had had to deal with or
consider in this type of scenario. TIA for any information. |
Title: os date, sysdate & time synchronization
- os date, sysdate & time synchronization Markham, Richard
- Jeff Holt
