| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: ** fall back backups
Having nothing at all to do with Oracle databases per se, I have long advocated a total system outage in excess of one hour for "fall back." IF (note the "if") this does not cause a material inconvenience to your business once a year between 1 AM and 3 AM Sunday morning, then it is an opportunity to completely eliminate time warp file stamps and events in your entire system. Notice that this in not needed at all for "spring ahead", or ever if you run your system on constant timeframes (like GMT worldwide).
This has nothing whatever to do with any particular known problem and everything to do with the improvement in certainty about what happenned when and establishing a sequence of events. If the value of easily establishing an order of events is less than the cost of shutting down for a small window once a year, then don't do it.
Handling "fall back" has in fact escaped the imagination of many overall applications systems designers over the years. Unless shutting down is really pretty inconvenient, I prefer to skip the test.
I can't remember if anyone has actually implemented a "run slow" timer to nearly completely eliminate all problems by running the wall clock at half speed for two hours beginning at 1 AM. I do remember discussing that with vendors in the early to mid 1990's in conjunction with MOSES.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mercadante, Thomas F
(LABOR)
Sent: Monday, October 31, 2005 7:40 AM
To: jcave_at_ddbcinc.com; ajoshi977_at_yahoo.com; oracle-l_at_freelists.org
Subject: RE: ** fall back backups
Justin,
I agree. I have never bounced the database because of clocks changing. All should be aware of when the sysadmins changed the clocks on the database server though. Especially if you are in a recovery situation!
Tom
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Justin Cave (DDBC)
Sent: Sunday, October 30, 2005 9:27 PM
To: ajoshi977_at_yahoo.com; oracle-l_at_freelists.org
Subject: RE: ** fall back backups
Did the analyst in the TAR say why he was recommending rebooting the database? I've never rebooted a database just because the clock changed and I can't see why it would make a difference. Doing a point-in-time recovery to a time between 1 and 2 AM (clocks went back an hour at 2 AM) will be problematic regardless of whether or not you reboot, but SCN based recover won't have a problem.
There may be applications out there that do not handle daylight savings well (i.e. a DATE column as a primary key that gets duplicates), in which case you may do something like take the server offline for an hour while the clock changes. As a general rule, though, there is no need to bounce a database just because you changed the operating system's clock.
Justin Cave <jcave_at_ddbcinc.com>
Distributed Database Consulting, Inc.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of A Joshi
Sent: Sunday, October 30, 2005 8:43 PM
To: oracle-l_at_freelists.org
Subject: ** fall back backups
Hi,
Now that clocks have been set back one hour (in us of a etc), it is time to bounce the databases. Since Oracle says it needs to be done (read some analyst in a TAR said it).
Is it for backups? I agree time based recovery to a point in time could lead to issues. However, will it affect the regular recovery until cancel which I think goes by SCN/log #. Please correct me if I am wrong.
Also once you have a couple of backups after the fall back resetting of clock is it still necessary to bounce databases and immediately take 2 backups?
Apart from backups does setting the clock back affect anything else on the database? Thanks
Yahoo! FareChase - Search multiple travel sites in one click.
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Oct 31 2005 - 07:44:44 CST
 |
 |