RE: DST Strategy

P.S.  However the database has to be restarted to initialize itself with
the new files.  i.e. select * from v$timezone_file will not reflect the
new version until after restart.

Joel Patterson
Database Administrator
joel.patterson@xxxxxxxxxxx
x72546
904  727-2546

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
Joel.Patterson@xxxxxxxxxxx
Sent: Thursday, February 22, 2007 8:54 AM
To: pbashir@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: DST Strategy

Looks good.  On the database side database restartability is not an
issue since it doesn't have to be shut down in the first place.  On the
java side I cannot comment.

I would go straight to version 4 and get it overwith, or eventually you
will do analogously the same thing again.  (which is what I am doing).  

The reason is that someone somewhere may decide to experiment with these
data types, and it can be confusing enough as it is before receiving the
wrong answers.  Then of course you need to update.

While your at it, check your DBTIMEZONE is what you want, not that it
makes a whole lot of difference, especially if you always use format
masks, but for the most part it is best that it is consistent, and it is
easy now.  It is for timestamp with local time zone.   But once using
the datatype, changing DBTIMEZONE is hardly practical.



Joel Patterson
Database Administrator
joel.patterson@xxxxxxxxxxx
x72546
904  727-2546

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Parvez Bashir
Sent: Wednesday, February 21, 2007 10:51 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: DST Strategy

Hi all,

Our DB team came up with the following DST strategy in an attempt to
balance 
risk with patch application resource costs for a target space of 73
dev/test 
and 55 production databases (2 8i, 35 9i, 18 10g).

This includes Solaris, Aix, and Linux servers.

Note: OS DST TZ patches have been applied across the board by SA's. We
are 
currently on an active migration path from Oracle 9i to Oracle 10g.

================
1. Oracle 8i DST Patches
================

No action required by Oracle. None taken. We have no 8i databases with
JVM 
installed.

======================
2. Oracle 9i TimeZone DST Patches
======================

We have no time zone columns in database and no PL/SQL code with time
zone 
types. No action taken.

=======================
3. Oracle 10g TimeZone DST Patches
=======================

We have no time zone columns (outside of the dictionary) in the
database. We 
applied TZ patches to all Oracle 10g databases. However, we did not
alter 
any data in the data dictionary after the utlzuv2.sql output (after 
evaluating a metalink note).

===================
4. Oracle 9i OJVM DST Patches
===================

We have several databases with OJVM is installed. Only two of these 
databases contain java objects. One of the databases with the Java
objects 
does not reference time. The other uses java time but not time zone. We
are 
planning to apply the patch in the later DB.

=====================
5. Oracle 10g  OJVM DST Patches
=====================

We are applying OJVM DST patches across the board for all 10g databases
with 
JVM installed.

=========
6. Grid Control
=========

We are evaluating the patch/work around.

Any comments on the above strategy? Are we on a relatively safe path?
What 
is the worst that can happen if a DST patch (TZ or JVM) is not applied?
Are 
there any potential issues with database restartability?

Parvez

_________________________________________________________________
Find a local pizza place, movie theater, and more....then map the best
route! 
http://maps.live.com/?icid=hmtag1&FORM=MGAC01

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


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


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


Other related posts: