RE: Oracle and DST changes

  • From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
  • To: "Mercadante, Thomas F \(LABOR\)" <Thomas.Mercadante@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 23 Jan 2007 11:42:27 -0700

Okay, thanks for setting me straight.  After a few hours navigating all
the notes, I think I have it figured out now and there are a few key
things I'd like to clear up in case anyone else is as confused as I was:
 
1) My count of 159 columns yesterday was wrong.  I got that by querying
dba_tab_columns, but I forgot that view also contains VIEW columns.
Today, I ran the query from Metalink 402614.1, and it showed that I
really have only 56 TSTZ columns in actual tables.

2) Metalink 396671.1 seems to clear up the confusion we had between your
findings with utltzuv2.sql and the statement I quoted from Metalink
359145.1.  Under the sub heading "Data dictionary tables listed in
results of utltzuv2.sql", it states that most dictionary columns only
use offsets rather than named timezones, so even though they are TSTZ
columns, the data is not affected.

3) Even if data is stored with an affected time zone, the data will not
be affected if it isn't in an affected time frame (i.e. after 3/11/07
for US time zones). 

4) On 10g, even if you don't currently have any affected data, you
should probably install the patch now to prevent affected data from
being inserted later and then having to be backed up and restored during
the patching.

Metalink 402614.1 covers all the above topics in more detail - I highly
recommend reading this one.

In Oracle's defense, I should add that there wasn't really any
inconsistency, because the quote I took from Metalink 359145.1 does
clearly state that 10.2 dictionary only needs to be patched if the data
"uses the affected time zones".  The confusion was my fault because I
assumed that it would be using affected time zones simply because we're
running our system in the U.S., but since it uses offsets rather than
named time zones, that is not the case.

I hope that helps and doesn't just add to the confusion.

Regards,
Brandon



________________________________

From: Mercadante, Thomas F (LABOR)
[mailto:Thomas.Mercadante@xxxxxxxxxxxxxxxxx] 


I saw that and reran the utltzuv2.sql file against my 10g database
(10.2.0.2) and it reports nothing to be concerned about.  How's that for
inconsistency?

Privileged/Confidential Information may be contained in this message or 
attachments hereto. Please advise immediately if you or your employer do not 
consent to Internet email for messages of this kind. Opinions, conclusions and 
other information in this message that do not relate to the official business 
of this company shall be understood as neither given nor endorsed by it.

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


Other related posts: