RE: Large system level date changed

on a test system you may choose to verify that the ancient solution to this problem still works: Grandfather all your arch, trc and dump files by directory to avoid born date and dlm confusion on the files, Set the system clock ahead, Start the database (preferably in restricted mode so no transactions are flying past), set the clock back, then open the database to full access.  

IF that works, then try to avoid shutdown until you are "close enough" to the time horizon. I'm not aware whether Oracle has published the details of
"reasonable upper limit" calculation so you can tell in advance whether the
error will raise. If this is a non-fatal ORA-600 (which used to be the null set, but that has changed) you might also be okay to ignore it if you know it is actually okay.  

Of course if you don't need to do a live test on production, just don't.  

I usually recommend that if it is at all possible a one hour two minute shutdown on fall back time change is a good idea, and an "as brief as possible" outage springing ahead keeps all time machine effects out of the system and database. Of course that is not possible for all environments. It is not that things should break, but rather, what is the safest and least confusing compared to the cost of a short blip in the spring and 62 minutes or so in the fall.  

Your mileage may vary, and there are many ways to skin the cat of avoiding confusion of which file came first when an hour is rerun in the fall back, pick your own favorite  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Smith, Steven K - MSHA
Sent: Monday, February 12, 2007 10:56 AM To: oracle-l_at_freelists.org
Subject: Large system level date changed  

Testing for the DST time changes is being planned here. It's actually going to have a minimal impact, but the testing needs to happen. Anyway, the request is to change the server level dates to the second Sunday in March to simulate the DST change.  

I understand that Oracle should/doesn't use the system dates to keep transaction continuity. I was about to give my input that changing the system date should not have an issue on the database itself until I ran into metalink note # 253977.1  

That note says:  

"While opening the database, Oracle compares the given SCN value
with the reasonable upper limit value calculated based on the system date. If Oracle detects the provided scn is too large, ORA-600[2252] would be raised."  

Now I'm a little concerned that when we change the system date back to the current correct date, I might have issues.  

Anyone have any experience with this?  

Steve Smith

Envision Technology Partners / MSHA MSIS Team

Desk: 303-231-5499    

--
http://www.freelists.org/webpage/oracle-l