DSTv15 Update For Oracle 11gR2

Applying the DSTv15 update for the Oracle Database (Doc ID 1274498.
1)
In this Document
Purpose
Scope and Application
Applying the DSTv15 update for the Oracle Database
1) What is my current installed DST version?
2) 9i, 10g and 11.1 only: What to check before applying the RDBMS DSTv15 p
atch 10272702
3) 9i, 10g and 11.1 only: You have affected TSTZ data stored (sys_tzuv2_tem
ptab returns rows).
4) 9i, 10g and 11.1 only: Applying the RDBMS DSTv15 patch 10272702
5) Applying the RDBMS DSTv15 patch on Oracle RDBMS 11gR2 (11.2.0.1 or highe
r)
6) The OJVM DSTv15 patch.
7) Conflict between Patch 9119284 (PSU 10.2.0.4.3) or patch 9352164 (PSU 10
.2.0.4.4) and the DST codefix patch 7695070
References
--------------------------------------------------------------------------------
Applies to:
Oracle Server - Enterprise Edition - Version: 9.0.1.0 to 11.2.0.2 - Release: 9.0
.1 to 11.2
Information in this document applies to any platform.
Purpose
The DSTv15 update includes the timezone information from the Olson ( ftp://elsie
.nci.nih.gov/pub ) data tzdata2010o.tar and contains all previous Oracle RDBMS D
ST updates.
An complete overview of timezone updates is found in Note 412160.1 Updated DST t
ransitions and new Time Zones in Oracle Time Zone File patches.
DSTv14 was the last RDBMS DST update to provide pro-active (free) 9.2.0.8 RDBMS
DST updates.
If there is need for RDBMS DST patches on 9.2.0.8 after DSTv14 and the system ha
s an existing Extended Support contract for 9.2.0.8 or you want to buy an Extend
ed Support contract for 9.2.0.8 please log a SR referring to this note.
Compared to DSTv14 this is the list of updated timezones:
Africa/Cairo, Egypt , America/Bahia_Banderas, Asia/Amman, Asia/Gaza, Europe/Hel

sinki, Pacific/Fiji, Pacific/Apia, Asia/Hong_Kong, Hongkong, Europe/Mariehamn

This note will give an overview on what checks to perform before applying the DS
Tv15 update.
Please note that SYSDATE is NOT affected by "Oracle DST patches" seen SYSDATE is
purely depending on the OS to get the time.
So even an "unpatched database" will return a correct SYSDATE if the server (OS)
time is correct.
For "sysdate" you do not need any DST patch Note 227334.1 Dates & Calendars - Fr
equently Asked Questions
For more information about Timestamp with (local) Time Zone please check Note 34
0512.1 Timestamps & time zones - Frequently Asked Questions

For 10g and up:
SQL> conn / as sysdba

Connected.
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
11
For 9i please see Note 412160.1 Updated DST transitions and new Time Zones in Or
acle Time Zone File patches
When applying DSTv15 to Oracle RDBMS 11.2 ( 11.2.0.1 , 11.2.0.2 ...) go directl
y to point 5), there is no need to run scripts before applying the DSTv15 patch
on Oracle RDBMS 11.2.0.1 and higher.
2) 9i, 10g and 11.1 only: What to check before applying the RDBMS DSTv15 patch
10272702
2a) Check if you have stored TSLTZ (TIMESTAMP WITH LOCAL TIME ZONE) data.
If you have user data that uses TSLTZ format then this needs to be checked manua
lly. There is no automated way to discover affected data.
Oracle uses by default no TSLTZ in the datadictionary.
To find out whether you have TSLTZ columns, use this query which will return all
TSLTZ columns.
select c.owner || '.' || c.table_name || '(' || c.column_name || ') -'

|| c.data_type || ' ' col
from dba_tab_cols c, dba_objects o
where c.data_type like '%LOCAL TIME ZONE'
and c.owner=o.owner
and c.table_name = o.object_name
and o.object_type = 'TABLE'
order by col
/
If this select returns no rows simply goto point 2b)
If this select returns rows then please see Note 756454.1 TSLTZ (TIMESTAMP WITH
LOCAL TIME ZONE) data and DST updates before going to point 2b).
2b) Check if you have stored affected TSTZ (TIMESTAMP WITH TIME ZONE) data.
For TSTZ data types you need to run utltzuv15.sql to see if you have TSTZ data u
sing the changed timezones seen any TSTZ data using the timezones who changed (c
ompared to your current DST version) need to be saved as plain text (Varchar2) b
efore applying the RDBMS DSTv15 patch and restored afterwards.
2b1) Installing utltzuv15.sql
Download and unzip utltzuv15.sql by clicking on the link.
The location of utltzuv15.sql is not critical, we suggest however to save it in
$ORACLE_HOME/rdbms/admin directory of the server $ORACLE_HOME.
2b2) running utltzuv15.sql
Note: utltzuv15.sql needs to be executed using sqlplus from the server's $ORACLE
_HOME.

Connected.
SQL> @?/rdbms/admin/utltzuv15.sql
DROP TABLE sys.sys_tzuv2_temptab CASCADE CONSTRAINTS
*
ERROR at line 1:
ORA-00942: table or view does not exist
Table created.
DROP TABLE sys.sys_tzuv2_affected_regions CASCADE CONSTRAINTS
*
ERROR at line 1:
Table created.
Your current timezone version is 11!
.
Do a select * from sys.sys_tzuv2_temptab; to see if any TIMEZONE
WITH TIMEZONE data is affected by version 15 transition rules.
.
Any table with YES in the nested_tab column (last column) needs
a manual check as these are nested tables.
PL/SQL procedure successfully completed.
2b3) After running utltzuv15.sql, you need to select sys.sys_tzuv2_temptab :

Connected.
SQL> select * from sys.sys_tzuv2_temptab;
no rows selected
If a "select * from sys.sys_tzuv2_temptab;" gives no rows then there is no actio
n to take you can simply apply the RDBMS DSTv15 patch without action on stored T
STZ data.
Goto point 4) in this note.
If a "select * from sys.sys_tzuv2_temptab;" give(s) affected TSTZ data then you
need to back up the TSTZ data before applying the RDBMS DSTv15 patch.
3) 9i, 10g and 11.1 only: You have affected TSTZ data stored (sys_tzuv2_temptab
returns rows).
3a) If the database is a 9i system then all reported data is user data and all r
eported data needs to be saved as Varchar2 before applying the RDBMS DSTv15 patc
h.
There are scripts who automate this, for these scripts and more information on h
ow to save the data as varchar2 please see Note 756474.1 TSTZ (TIMESTAMP WITH TI
ME ZONE) data and DST updates.
3b) If the database is version 10.1 or higher then:
3b1) Check if there is something outside the Data Dictionary (= non-SYS / WMSYS
owned tables).
All reported data outside the SYS/WMSYS schema is user data and all this reporte
d user data needs to be saved as Varchar2 before applying the RDBMS DSTv15 patch
.
3b2) If sys_tzuv2_temptab returns SYS owned objects then this should be SYS.SCH
EDULER$_% columns. (DBMS_SCHEDULER objects). If you have other sys objects repor
ted then please log a SR.
Background information: A full overview of the Data Dictionary tables using TSTZ
datatype in 10g / 11g is found in: Note 402614.1 Time Zone Data in the Data Dic
tionary During a Time Zone File Update
The action for SYS.SCHEDULER$_% columns depends if you are using DBMS_SCHEDULER
for your own jobs or not. These are the standard Oracle provided DBMS_SCHEDULER
jobs and schedules for a 10g/11g (bold) database:
SQL> SELECT object_name FROM dba_objects WHERE object_id IN (SELECT obj# FROM sc
heduler$_window);
OBJECT_NAME
--------------------------------------------------------------------------------
MONDAY_WINDOW
TUESDAY_WINDOW
WEDNESDAY_WINDOW
THURSDAY_WINDOW
FRIDAY_WINDOW
SATURDAY_WINDOW
SUNDAY_WINDOW
WEEKNIGHT_WINDOW
WEEKEND_WINDOW
heduler$_job);
OBJECT_NAME
--------------------------------------------------------------------------------
PURGE_LOG
FGR$AUTOPURGE_JOB
GATHER_STATS_JOB
AUTO_SPACE_ADVISOR_JOB
RLM$EVTCLEANUP
RLM$SCHDNEGACTION
ORA$AUTOTASK_CLEAN
HM_CREATE_OFFLINE_DICTIONARY
DRA_REEVALUATE_OPEN_FAILURES
MGMT_CONFIG_JOB
MGMT_STATS_CONFIG_JOB
BSLN_MAINTAIN_STATS_JOB
XMLDB_NFS_CLEANUP_JOB
If you have ORACLE_OCM installed in 10g you will also see the MGMT_CONFIG_JOB an
d MGMT_STATS_CONFIG_JOB jobs.
The standard oracle provided 10g/11g usage of TZ data in DBMS_SCHEDULER is not c
ritical, the standard internal jobs don't depend on being executed on a exact ho
ur. Hence for the build in jobs no action is needed, you can however always chec
k or alter the execution time after applying the RDBMS DSTv15 patch if needed.
You can have basically 3 situations for sys objects...
3b2a) If you have only SYS.SCHEDULER$_% columns reported in sys_tzuv2_temptab an
d only the build in DBMS_SCHEDULER jobs defined then there is no action to take
on SYS objects before applying the RDBMS DSTv15 patch. Please do not forget to t
ake action on user data if there is any reported in sys_tzuv2_temptab.
Goto point 4)
3b2b) If you have only SYS.SCHEDULER$_% columns reported in sys_tzuv2_temptab an
d you have your own DBMS_SCHEDULER jobs defined, and they are time critical, the
n we suggest to check the start times after applying the RDBMS DSTv15 patch and
adapt if needed. Reading Note 467722.1 DBMS_SCHEDULER And Time Zones ( DST ) Exp
lained. might be useful for this.
Alternatively those jobs can be dropped before applying the RDBMS DSTv15 patch a
nd resubmit them after applying the RDBMS DSTv15 patch.
Please do not forget to take action on user data if there is any reported in sys
_tzuv2_temptab.
Goto point 4)
3b2c) If you have other sys objects reported then SYS.SCHEDULER$_% columns when
querying sys_tzuv2_temptab then it might be a good idea to log a SR before apply
ing the RDBMS DSTv15 Patch.
4a) Supported versions and platforms.
Supported versions are inline with Note 209768.1 Database, FMW, Em Grid Control,
and OCS Software Error Correction Support Policy, see also Point G. in note 412
160.1
In addition the RDBMS DSTv15 update is released pro-actively for the following v
ersions: 11.1.0.7 , 10.2.0.5, 10.2.0.4 and 10.1.0.5 and ported to the following
platforms: Linux 32, Linux 64, Win 32, Win x86-64, AIX POWER 64 bit, HP PA, HP
Itanium, Solaris Sparc 64, Solaris x86-64 and Open VMS.
Note that the DSv15 patch needs Patch 7695070 to be in place for versions 11.1.
0.7 , 11.1.0.6, 10.2.0.4 and lower.
Patch 7695070 is not needed for 10.2.0.5.
For 11.2.0.1, 11.2.0.2 or higher. see point 5) in this note
DSTv14 was the last RDBMS DST patch to be released for 9.2.0.8 unless there is a
n Extended Support contract for your system.
If there is need for a backport of DSTv15 (and the required Patch 7695070 ) to c
urrent patchsets for other platforms please log a SR.
Note that a backport to a non-current patchset version/platform combination will
only possible for customers having an existing Extended Support contract for th
at version/platform combination.
4b) Patch 7695070 needs to be applied before the RDBMS DSTv15 patch 10272702 can
be installed.
Unlike DSTv9 and lower patches the DSTv15 patch needs to have 2 codefixes in pl
ace (Bug 7695070 and bug 7395472) to work. For Unix platforms they are combined
in patch 7695070.
These are included in 10.2.0.5, so 10.2.0.5 does NOT need any patch besides the
actual DSTv15 patch.
* All non-windows platforms (except 10.2.0.5 ) need to have patch 7695070 applie
d BEFORE applying the DSTv15 Patch 10272702 .
Note that patch 7695070 includes the fix for bug 7395472. No need to apply patch
7395472 separated. If patch 7395472 is installed it will be rollbacked when ap
plying patch 7695070.
If you have the DSTv10 patch 7580744 installed this will also be rollbacked when
applying Patch 7695070.
For Opatch questions please see Note 242993.1 OPATCH FAQ
* All windows platforms (except 10.2.0.5) need to have a Windows patch bundle ap
plied that includes the fixes for Bug 7695070 and bug 7395472 . The windows DSTv
15 patch 10272702 itself does not include the fixes for Bug 7695070 and/or bug 7
395472.
For windows platforms you need to apply one of these patch set bundles:
* 11.1.0.7.0 Patch 15 or higher
* 11.1.0.6 Patch 18 or higher
For availability of these Windows patch bundles please see Note 161549.1 Oracle
Database Server and Networking Patches for Microsoft Platforms.
This also implicates that you CANNOT simply copy the 2 .dat files anymore to upd
ate an older version where no DSTv15 patch is available for (unless this version
has also the fixes for Bug 7695070 and bug 7395472 in place) .
Applying the DST patch without the needed codefix may result in errors like for
example
SP2-1503: Unable to initialize Oracle call interface
SP2-0152: ORACLE may not be functioning properly
4c) Apply the RDBMS DSTv15 patch 10272702 on the server side.
Again, before applying the DSTv15 patch you should make sure that
* any affected TSTZ data reported by utltzuv11.sql is saved as Varchar2 as docum
ented in Note 756474.1 TSTZ (TIMESTAMP WITH TIME ZONE) data and DST updates
* for SYS.SCHEDULER$_% columns you checked the jobs.
For Unix platforms

* make sure patch 7695070 is applied using Opatch or that you are on 10.2.0.5.
* then DSTv15 Patch 10272702 can be applied using Opatch
For Opatch see: Note 274526.1 How to download and install opatch (generic platfo
rm).
For AIX and Linux you need to do a "Relink all" after applying patch 7695070.
For Windows platforms you will need to
* make sure the required Windows patch bundle is applied (point 4b) or that you
are on 10.2.0.5.
rm).
4d) Restore any TSTZ data that was saved as varchar2 (if any) after applying the
RDBMS DSTv15 patch and check the execution time of DBMS_SCHEDULER jobs.
4e) Apply the RDBMS DSTv15 patch 10272702 also on affected clients.
For Unix clients
Note that there are no "client patchsets", if you need to patch for example a 10
.2.0.1 client to 10.2.0.4 then you need to apply the "server" 10.2.0.4 patchset
to this client. Also for clients patch 7695070 need to be applied before you can
apply the DSTv15 patch 10272702 to the client.
Again, 10.2.0.5 does not need any patch besides the actual DSTv15 patch 10272702
For AIX and Linux you need to do a "Relink all" after applying patch 7695070 .
For Windows clients you will need to
* If needed apply the "server" patchset to the client (if you need to patch for
example a 10.2.0.1 client to 10.2.0.4 then you need to apply the "server" 10.2.0
.4 patchset to this client.).
* apply the required Windows patch bundle (point 4b) to the client. Not needed f
or 10.2.0.5
OR manually:
* unzip DSTv15 patch 10272702
* goto %ORACLE_HOME%\oracore\zoneinfo and take a backup of timezone.dat, timezlr
g.dat and readme.txt
* copy timezone.dat, timezlrg.dat and readme.txt from the unzipped patch 1027270
2 directory to %ORACLE_HOME%\oracore\zoneinfo
5) Applying the RDBMS DSTv15 patch on Oracle RDBMS 11gR2 (11.2.0.1 or higher)
The RDBMS DSTv15 update for 11.2.0.1 and 11.2.0.2 is released pro-actively for t
he following platforms: Linux 32, Linux 64, Win 32, Win x86-64, AIX POWER 64 bit
, HP PA, HP Itanium, Solaris Sparc 64, Solaris x86-64 and Open VMS.
There is for 11.2.0.1 and 11.2.0.2 no need to apply any "code fix" (like on most
lower versions) before you can apply the actual DSTv15 patch.
The RDBMS DSTv15 update is included in 11.2.0.3 and later, so there are no 11.2.
0.3 or later DSTv15 patches.
The way RDBMS DST updates are applied is considerably enhanced in Oracle 11gR2 a
nd there is no need any more to use utltzuvxx.sql scripts before applying a DST
patch to the ORACLE_HOME.
After a DST patch is installed in an 11.2 $ORACLE_HOME there are steps who need
to be done to change a existing database to use this newer DST version.
Simply applying the RDBMS DST patch and restarting the database will NOT enable
the new applied RDBMS DST version patch (like it did in pre-11.2 versions).
For 11.2.0.1 and 11.2.0.2 please download the DSTv15 Patch 10272702 for your pl
atform and then see Note 977512.1 Updating the RDBMS DST version in 11gR2 (11.2.
0.1 and up) using DBMS_DST.
For 11.2.0.3 and later there is no patch to download, it is included in the patc
hset. follow Note 977512.1 Updating the RDBMS DST version in 11gR2 (11.2.0.1 and
up) using DBMS_DST.to update every database in the 11.2.0.3 (or up) home to DST
v15.
There is also a corresponding OJVM DSTv15 Patch 10406470, who is pro-actively re
leased for 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1 and 11.2.0.2.
There are very few applications who actually use the DST information of the OJVM
, hence this patch is not proactively backported to older releases. If you are o
n a supported version or have an existing Extended Support contract then you can
of course request a backport if your application uses the OJVM DST information.
This patch is platform generic, please see the readme for installation instruct
ions.
To apply the patch you need to
* apply Patch 10406470 using opatch
Cd to patch 10406470 directory

./opatch apply
* then connect as SYS and run script $ORACLE_HOME/javavm/admin/fixTZa
SQL> @?/javavm/admin/fixTZa.sql
Java created.
No errors.
Java altered.
No errors.
Package created.
No errors.
Package body created.
No errors.
Call completed.
Testing various timezone DST attributes
FAILED for Pacific/Auckland 10:0:0 10/1/2007
FAILED for Pacific/Chatham 10:0:0 10/1/2007
...
FAILED for Pacific/Chatham 1396706399999 45900000 3600000
##
Bug is in fact present, so this patch is needed
##
(Perhaps) modifying ild_ub1$ for rehotloading of sun/util/calendar/ZoneInfoFile
obj# = 432434
nbytes %d = 64512, 1st read = 64512, 2nd read = -1
87 379782 369648 10134 joxbtflag>>8 = 3
===
########################################################
Proceed by restarting the database and running script
fixTZb
########################################################
note that the "FAILED " meassages are normal and part of the patching process an
d not an error/problem
If the output say to run fixTZb (it almost always will) then do:
Step1: If needed, edit init.ora and set cluster_database=FALSE
Step2: As SYS shutdown database: SQL> shutdown
Step3: Start the database in migrate: SQL> startup migrate
Step4: Execute the script SQL> $ORACLE_HOME/javavm/admin/fixTZb
SQL> @?/javavm/admin/fixTZb.sql
Call completed.
########################################################
Bug is no longer present. Patch succeeded.
########################################################
drop java source fixTZ
drop package fixTZ
if you have the message "Bug is no longer present. Patch succeeded." then everyt
hing is fine.
start the database again normally:
Step5 : shutdown the database: SQL> shutdown

Step6 : If needed, edit init.ora back to cluster_database=TRUE
Step7 : Start Database without startup migrate: SQL> startup
7) Conflict between Patch 9119284 (PSU 10.2.0.4.3) or patch 9352164 (PSU 10.2.0.
4.4) and the DST codefix patch 7695070
There is a conflict when applying Patch 9119284 (PSU 10.2.0.4.3)/patch 9352164 (
PSU 10.2.0.4.4) with patch 7695070 for 10.2.0.4.0, apply patch 7695070 for 10.2.
0.4.3/10.2.0.4.4 after applying the PSU
If you have already installed DSTv15 and apply Patch 9119284 (PSU 10.2.0.4.3)/pa
tch 9352164 (PSU 10.2.0.4.4) afterwards then rollback patch 7695070 and then re-
apply patch 7695070 for 10.2.0.4.3/10.2.0.4.4 right after after applying the PSU
(= before starting the database again).
There is no need to re-apply the actual DSTv15 patch 10272702 when applying PSU
10.2.0.4.3/10.2.0.4.4 on an database home that is already DSTv15.
References
NOTE:412160.1 - Updated DST transitions and new Time Zones in Oracle Time Zone F
ile patches
NOTE:977512.1 - Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using
DBMS_DST
################################################################################
###############################################
Applying the DSTv14 update for the Oracle Database (Doc ID 1109924.1)
Modified Date LabelModifiedModified Date01-APR-2011Document Type LabelTypeDocu

ment TypeBULLETINStatusPUBLISHED(EXTERNAL)Priority3To Bottom
In this Document
Purpose
2) 9i, 10g and 11.1 only: What to check before applying the RDBMS DSTv14 p
atch 9742718
3) 9i, 10g and 11.1 only: You have affected TSTZ data stored (sys_tzuv2_tem
ptab returns rows).
5) Applying the RDBMS DSTv14 patch on Oracle RDBMS 11gR2
7) Conflict between Patch 9119284 (PSU 10.2.0.4.3) or patch 9352164 (PSU 10
.2.0.4.4) and the DST codefix patch 7695070
8) 11.2.0.1 only: Conflict between DSTv13 RDBMS patch 9146268 and DSTv14 RD
BMS patch 9742718
References
--------------------------------------------------------------------------------
Applies to:
Oracle Server - Enterprise Edition - Version: 9.0.1.0 to 11.2.0.1 - Release: 9.0
.1 to 11.2
Purpose
The DSTv14 update includes the timezone information from the Olson ( ftp://elsie
.nci.nih.gov/pub ) data tzdata2010j.tar and contains all previous Oracle DST upd
ates.
Newer DST updates are out. A complete overview of timezone updates is found in N
ote 412160.1 Updated DST transitions and new Time Zones in Oracle Time Zone File
patches.
DSTv14 will be the last RDBMS DST update to provide pro-active (free) 9.2 RDBMS
DST updates.
If there is need for future RDBMS DST patches on 9.2.0.8 and have an existing Ex
tended Support contract for 9.2.0.8 or want to buy an Extended Support contract
for 9.2.0.8 please log a SR referring to this note.
Compared to DSTv13 this is the list of non-historical (later then 1979) updated
timezones:
Africa/Casablanca, Africa/Tunis, America/Argentina/San_Luis, America/Tijuana, Am
erica/Santiago, America/Asuncion, Antarctica/Casey, Antarctica/Davis, Asia/Dacca
, Asia/Taipei, Asia/Karachi, Asia/Gaza, Asia/Damascus, Asia/Kamchatka, Asia/Anad
yr, Europe/Samara, Pacific/Easter,Pacific/Fiji,Pacific/Apia, America/Ensenada,Ch
ile/Continental, Asia/Dhaka, ROC, Chile/EasterIsland, Mexico/BajaNorte

This note will give an overview on what checks to perform before applying the DS
Tv14 update.
Please note that SYSDATE is NOT affected by "Oracle DST patches" seen SYSDATE is
purely depending on the OS to get the time.
So even an "unpatched database" will return a correct SYSDATE if the server (OS)
time is correct.
For "sysdate" you do not need any DST patch Note 227334.1 Dates & Calendars - Fr
equently Asked Questions
For more information about Timestamp with (local) Time Zone please check Note 34
0512.1 Timestamps & time zones - Frequently Asked Questions

For 10g and up:

Connected.
VERSION
----------
11
For 9i please see Note 412160.1 Updated DST transitions and new Time Zones in Or
acle Time Zone File patches
When applying DSTv14 to Oracle RDBMS 11.2 go directly to point 5), there is no n
eed to run scripts before applying the DSTv14 patch on ORacle RDBMS 11.2.0.1 and
higher.
2) 9i, 10g and 11.1 only: What to check before applying the RDBMS DSTv14 patch
9742718
2a) Check if you have stored TSLTZ (TIMESTAMP WITH LOCAL TIME ZONE) data.
If you have user data that uses TSLTZ format then this needs to be checked manua
lly. There is no automated way to discover affected data.
Oracle uses by default no TSLTZ in the datadictionary.
To find out whether you have TSLTZ columns, use this query which will return all
TSLTZ columns.
select c.owner || '.' || c.table_name || '(' || c.column_name || ') -'

|| c.data_type || ' ' col
where c.data_type like '%LOCAL TIME ZONE'
and c.owner=o.owner
order by col
/
If this select returns no rows simply goto point 2b)
If this select returns rows then please see Note 756454.1 TSLTZ (TIMESTAMP WITH
LOCAL TIME ZONE) data and DST updates before going to point 2b).
2b) Check if you have stored affected TSTZ (TIMESTAMP WITH TIME ZONE) data.
For TSTZ data types you need to run utltzuv14.sql to see if you have TSTZ data u
sing the changed timezones seen any TSTZ data using the timezones who changed (c
ompared to your current DST version) need to be saved as plain text (Varchar2) b
efore applying the RDBMS DSTv14 patch and restored afterwards.
2b1) Installing utltzuv14.sql
Download and unzip utltzuv14.sql by clicking on the link.
The location of utltzuv14.sql is not critical, we suggest however to save it in
$ORACLE_HOME/rdbms/admin directory of the server $ORACLE_HOME.
2b2) running utltzuv14.sql
Note: utltzuv14.sql needs to be runned from the sqlplus executable from the serv
er's $ORACLE_HOME.

Connected.
SQL> @?/rdbms/admin/utltzuv14.sql
DROP TABLE sys.sys_tzuv2_temptab CASCADE CONSTRAINTS
*
ERROR at line 1:
Table created.
DROP TABLE sys.sys_tzuv2_affected_regions CASCADE CONSTRAINTS
*
ERROR at line 1:
Table created.
Your current timezone version is 11!
.
Do a select * from sys.sys_tzuv2_temptab; to see if any TIMEZONE
WITH TIMEZONE data is affected by version 14 transition rules.
.
Any table with YES in the nested_tab column (last column) needs
a manual check as these are nested tables.
2b3) After running utltzuv14.sql, you need to select sys.sys_tzuv2_temptab; :

Connected.
SQL> select * from sys.sys_tzuv2_temptab;
no rows selected
If a "select * from sys.sys_tzuv2_temptab;" gives no rows then there is no actio
n to take you can simply apply the RDBMS DSTv14 patch without action on stored T
STZ data.
If a "select * from sys.sys_tzuv2_temptab;" give(s) affected TSTZ data then you
need to back up the TSTZ data before applying the RDBMS DSTv14 patch.
3) 9i, 10g and 11.1 only: You have affected TSTZ data stored (sys_tzuv2_temptab
returns rows).
3a) If the database is a 9i system then all reported data is user data and all r
eported data needs to be saved as Varchar2 before applying the RDBMS DSTv14 patc
h.
3b) If the database is version 10.1 or higher then:
3b1) Check if there is something outside the Data Dictionary (= non-SYS / WMSYS
owned tables).
All reported data outside the SYS/WMSYS schema is user data and all this reporte
d user data needs to be saved as Varchar2 before applying the RDBMS DSTv14 patch
.
3b2) If sys_tzuv2_temptab returns SYS owned objects then this should be SYS.SCH
EDULER$_% columns. (DBMS_SCHEDULER objects). If you have other sys objects repor
ted then please log a SR.
Background information: A full overview of the Data Dictionary tables using TSTZ
datatype in 10g / 11g is found in: Note 402614.1 Time Zone Data in the Data Dic
tionary During a Time Zone File Update
The action for SYS.SCHEDULER$_% columns depends if you are using DBMS_SCHEDULER
for your own jobs or not. These are the standard Oracle provided DBMS_SCHEDULER
jobs and schedules for a 10g/11g (bold) database:
heduler$_window);
OBJECT_NAME
--------------------------------------------------------------------------------
MONDAY_WINDOW
TUESDAY_WINDOW
WEDNESDAY_WINDOW
THURSDAY_WINDOW
FRIDAY_WINDOW
SATURDAY_WINDOW
SUNDAY_WINDOW
WEEKNIGHT_WINDOW
WEEKEND_WINDOW
heduler$_job);
OBJECT_NAME
--------------------------------------------------------------------------------
PURGE_LOG
FGR$AUTOPURGE_JOB
GATHER_STATS_JOB
AUTO_SPACE_ADVISOR_JOB
RLM$EVTCLEANUP
RLM$SCHDNEGACTION
ORA$AUTOTASK_CLEAN
HM_CREATE_OFFLINE_DICTIONARY
DRA_REEVALUATE_OPEN_FAILURES
MGMT_CONFIG_JOB
MGMT_STATS_CONFIG_JOB
BSLN_MAINTAIN_STATS_JOB
XMLDB_NFS_CLEANUP_JOB
If you have ORACLE_OCM installed in 10g you will also see the MGMT_CONFIG_JOB an
d MGMT_STATS_CONFIG_JOB jobs.
The standard oracle provided 10g/11g usage of TZ data in DBMS_SCHEDULER is not c
ritical, the standard internal jobs don't depend on being executed on a exact ho
ur. Hence for the build in jobs no action is needed, you can however always chec
k or alter the execution time after applying the RDBMS DSTv14 patch if needed.
You can have basically 3 situations for sys objects...
3b2a) If you have only SYS.SCHEDULER$_% columns reported in sys_tzuv2_temptab an
d only the build in DBMS_SCHEDULER jobs defined then there is no action to take
on SYS objects before applying the RDBMS DSTv14 patch. Please do not forget to t
ake action on user data if there is any reported in sys_tzuv2_temptab.
Goto point 4)
3b2b) If you have only SYS.SCHEDULER$_% columns reported in sys_tzuv2_temptab an
d you have your own DBMS_SCHEDULER jobs defined, and they are time critical, the
n we suggest to drop those jobs before applying the RDBMS DSTv14 patch and resub
mit them after applying the RDBMS DSTv14 patch.
Alternatively you can check the start times after applying the RDBMS DSTv14 patc
h and adapt if needed. The Note 467722.1 DBMS_SCHEDULER And Time Zones ( DST ) E
xplained. might be useful to check.
Please do not forget to take action on user data if there is any reported in sys
_tzuv2_temptab.
Goto point 4)
3b2c) If you have other sys objects reported then SYS.SCHEDULER$_% columns when
querying sys_tzuv2_temptab then it might be a good idea to log a SR before apply
ing the RDBMS DSTv14 Patch.
4a) Supported versions and platforms.
Supported versions are inline with Note 209768.1 Database, FMW, Em Grid Control,
and OCS Software Error Correction Support Policy, see also Point G. in note 412
160.1
In addition the RDBMS DSTv14 update (and the required Patch 7695070 ) is release
d pro-actively for the following versions: 11.2.0.1, 11.1.0.7 , 10.2.0.5, 10.2.0
.4, 10.1.0.5, 9.2.0.8 and ported to the following platforms: Linux 32, Linux 64,
Win 32, Win x86-64, AIX POWER 64 bit, HP PA, HP Itanium, Solaris Sparc 64, Sola
ris x86-64 and Open VMS.
This is the last RDBMS DST patch to be released for 9.2.0.8 unless there is an E
xtended Support contract for your system.
If there is need for a backport of DSTv14 (and the required Patch 7695070 ) to c
urrent patchsets for other platforms please log a SR.
Note that a backport to a non-current patchset version/platform combination will
only possible for customers having an existing Extended Support contract for th
at version/platform combination.
4b) Patch 7695070 needs to be applied before the RDBMS DSTv14 patch 9742718 can
be installed.
Unlike DSTv9 and lower patches the DSTv14 patch needs to have 2 codefixes in pl
ace (Bug 7695070 and bug 7395472) to work. For Unix platforms they are combined
in patch 7695070.
These are included in 10.2.0.5, so 10.2.0.5 does NOT need any patch besides the
actual DSTv14 patch.
* All non-windows platforms (except 10.2.0.5) need to have patch 7695070 applied
BEFORE applying the DSTv14 Patch 9742718 .
Note that patch 7695070 includes the fix for bug 7395472. No need to apply patch
7395472 separated. If patch 7395472 is installed it will be rollbacked when ap
plying patch 7695070.
If you have the DSTv10 patch 7580744 installed this will also be rollbacked when
applying Patch 7695070.
* All windows platforms (except 10.2.0.5) need to have a Windows patch bundle ap
plied that includes the fixes for Bug 7695070 and bug 7395472 . The windows DSTv
14 patch 9742718 itself does not include the fixes for Bug 7695070 and/or bug 73
95472.
For windows platforms you need to apply one of these patch set bundles:
For availability of these Windows patch bundles please see Note 161549.1 Oracle
Database Server and Networking Patches for Microsoft Platforms.
This also implicates that you CANNOT simply copy the 2 .dat files anymore to upd
ate an older version where no DSTv14 patch is available for (unless this version
has also the fixes for Bug 7695070 and bug 7395472 in place) .
Applying the DST patch without the needed codefix may result in errors like for
example
SP2-1503: Unable to initialize Oracle call interface
SP2-0152: ORACLE may not be functioning properly
4c) Apply the RDBMS DSTv14 patch 9742718 on the server side.
Again, before applying the DSTv14 patch you should make sure that
* any affected TSTZ data reported by utltzuv11.sql is saved as Varchar2 as docum
ented in Note 756474.1 TSTZ (TIMESTAMP WITH TIME ZONE) data and DST updates
* for SYS.SCHEDULER$_% columns you checked the jobs.
For Unix platforms

* make sure patch 7695070 is applied using Opatch or that you are on 10.2.0.5.
rm).
For AIX you need to do a "Relink all" after applying patch 7695070.
For Windows platforms you will need to
* make sure the required Windows patch bundle is applied (point 4b) or that you
are on 10.2.0.5.
directory to %ORACLE_HOME%\oracore\zoneinfo
4d) Restore any TSTZ data that was saved as varchar2 (if any) after applying the
RDBMS DSTv14 patch and check the execution time of DBMS_SCHEDULER jobs.
4e) Apply the RDBMS DSTv14 patch 9742718 also on affected clients.
For Unix clients
Note that there are no "client patchsets", if you need to patch for example a 10
.2.0.1 client to 10.2.0.4 then you need to apply the "server" 10.2.0.4 patchset
to this client. Also for clients patch 7695070 need to be applied before you can
apply the DSTv14 patch 9742718 to the client.
Again, 10.2.0.5 does not need any patch besides the actual DSTv14 patch 9742718
For AIX you need to do a "Relink all" after applying patch 7695070 .
For Windows clients you will need to
* If needed apply the "server" patchset to the client (if you need to patch for
example a 10.2.0.1 client to 10.2.0.4 then you need to apply the "server" 10.2.0
.4 patchset to this client.).
* apply the required Windows patch bundle (point 4b) to the client. Not needed f
or 10.2.0.5
directory to %ORACLE_HOME%\oracore\zoneinfo
5) Applying the RDBMS DSTv14 patch on Oracle RDBMS 11gR2
The RDBMS DSTv14 update for 11.2.0.1 is released pro-actively for the following
platforms: Linux 32, Linux 64, Win 32, Win x86-64, AIX POWER 64 bit, HP PA, HP I
tanium, Solaris Sparc 64, Solaris x86-64 and Open VMS.
There is for 11.2.0.1 no need to apply any "code fix" (like on most lower versio
ns) before you can apply the actual DSTv14 patch.
The RDBMS DSTv14 update is included in 11.2.0.2 and later, so there are no 11.2.
0.2 or later DSTv14 patches.
The way RDBMS DST updates are applied is considerable enhanced in Oracle 11.2 an
d do not need anymore the checking using utltzuvxx.sql script and backing up of
TSTZ data before applying an DST patch to the ORACLE_HOME.
For 11.2.0.1 please download the DSTv14 Patch 9742718 for your platform in poin
t 8) of this note and then follow Note 977512.1 Updating the RDBMS DST version i
n 11gR2 (11.2.0.1 and up) using DBMS_DST to update every database in the 11.2.0.
1 home to DSTv14.
For 11.2.0.2 and later there is no patch to download, it is included in the patc
hset. follow Note 977512.1 Updating the RDBMS DST version in 11gR2 (11.2.0.1 an
d up) using DBMS_DST.to update every database in the 11.2.0.2 (or up) home to DS
Tv14.
There is also a corresponding OJVM DSTv14 Patch 9751299, who is pro-actively rel
eased for 10.2.0.4, 10.2.0.5, 11.1.0.7 and 11.2.0.1.
OJVM DSTv14 is included in 11.2.0.2.
There are very few applications who actually use the DST information of the OJVM
, hence this patch is not proactively backported to older releases. If you are o
n a supported version or have an existing Extended Support contract then you can
of course request a backport if your application uses the OJVM DST information.
This patch is platform generic, please see the readme for installation instruct
ions.
To apply the patch you need to
* apply Patch 9751299 using opatch
Cd to patch 9751299 directory

./opatch apply
* then connect as SYS and run script $ORACLE_HOME/javavm/admin/fixTZa
SQL> @?/javavm/admin/fixTZa.sql
Java created.
No errors.
Java altered.
No errors.
Package created.
No errors.
Package body created.
No errors.
Call completed.
FAILED for Pacific/Chatham 10:0:0 10/1/2007
...
##
##
(Perhaps) modifying ild_ub1$ for rehotloading of sun/util/calendar/ZoneInfoFile
obj# = 432434
nbytes %d = 64512, 1st read = 64512, 2nd read = -1
87 379782 369648 10134 joxbtflag>>8 = 3
===
########################################################
Proceed by restarting the database and running script
fixTZb
########################################################
note that the "FAILED " meassages are normal and part of the patching process an
d not an eror/problem
if the output say's to run fixTZb (it almost always will) then do
Step1: If needed, edit init.ora and set cluster_database=FALSE

Step2: As SYS shutdown database: SQL> shutdown
Step3: Start the database in migrate: SQL> startup migrate
Step4: Execute the script SQL> $ORACLE_HOME/javavm/admin/fixTZb
SQL> @?/javavm/admin/fixTZb.sql
Call completed.
########################################################
Bug is no longer present. Patch succeeded.
########################################################
drop java source fixTZ
drop package fixTZ
if you have the message "Bug is no longer present. Patch succeeded." then everyt
hing is fine.
start the database again normally:
Step5 : shutdown the database: SQL> shutdown

Step6 : If needed, edit init.ora back to cluster_database=TRUE
Step7 : Start Database without startup migrate: SQL> startup
7) Conflict between Patch 9119284 (PSU 10.2.0.4.3) or patch 9352164 (PSU 10.2.0.
4.4) and the DST codefix patch 7695070
There is a conflict when applying Patch 9119284 (PSU 10.2.0.4.3)/patch 9352164 (
PSU 10.2.0.4.4) with patch 7695070 for 10.2.0.4.0, apply patch 7695070 for 10.2
.0.4.3/10.2.0.4.4 after applying the PSU
If you have already installed DSTv14 and apply Patch 9119284 (PSU 10.2.0.4.3)/pa
tch 9352164 (PSU 10.2.0.4.4) afterwards then rollback patch 7695070 and then re-
apply patch 7695070 for 10.2.0.4.3/10.2.0.4.4 right after after applying the PSU
(= before starting the database again).
There is no need to re-apply the actual DSTv14 patch 9146268 when applying PSU 1
0.2.0.4.3/10.2.0.4.4 on an database home that is already DSTv14.
8) 11.2.0.1 only: Conflict between DSTv13 RDBMS patch 9146268 and DSTv14 RDBMS p
atch 9742718
Problem:
When applying DSTv14 on an 11.2.0.1 system that has DSTv13 installed Opatch will
detect an conflict between DSTv14 and DSTv13 when using the current available 1
1.2.0.1 RDBMS DSTv14 9742718 patch from MOS.
If you allow Opatch to rollback patch 9146268 and then restart the DSTv13 databa
se you see in the alert.log
Failed to find timezone data file # 13 (DST_4)
Daylight Saving Time feature is disabledbecause the DSTv13 patch is gone.
If you try to upgrade from DSTv13 to DSTv14 you see
SQL> exec DBMS_DST.BEGIN_PREPARE(14);
BEGIN DBMS_DST.BEGIN_PREPARE(14); END;
*
ERROR at line 1:
ORA-56923: database properties related to time zone version are not set up
properly
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.DBMS_DST", line 1269
ORA-06512: at line 1
Solution:
There is no real reason why DSTv14 should conflict with DSTv13 on 11.2.0.1 seen
in 11.2.0.1 the different DST patches can co-exist in the same oracle_home.
On older version than 11.2.0.1 applying a newer RDBMS DST patch WILL rollback th
e older RDBMS DST patch (if installed) - this is normal and intended.
The "conflict" between DSTv14 and DSTv13 on 11.2.0.1 comes from the fact that bo
th DSTv13 and DSTv14 include a readme.txt in files\oracore\zoneinfo, hence the D
STv14 patch replaces this file and a conflict is raised.
The 11.2.0.1 RDBMS DSTv14 9742718 patches adapted to avoid this (unneeded) confl
ict.can be downloaded here. The only difference is that these patches have a rea
dme_14.txt and hence there is no conflict. There is no difference in the timezon
e file itself.
For Solaris Operating System Intel x86-64 (64-bit) , Linux Intel (32bit), Linux
x86-64 (64-bit), Microsoft Windows x86 (32bit) or Microsoft Windows x64 (64-bit
) use this 9742718_112010_LE.zip patch.
For Solaris SPARC (64-BIT), HP Itanium (IA64), HP-UX PA-RISC (64-bit), AIX-Based
Systems (64-bit) use this 9742718_112010_BE.zip patch.
References
ile patches
NOTE:977512.1 - Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using
DBMS_DST
################################################################################
##############################################
Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST (Doc ID
977512.1)
Modified Date LabelModifiedModified Date15-MAR-2011Document Type LabelTypeDocu

ment TypeBULLETINStatusPUBLISHED(EXTERNAL)Priority3To Bottom
In this Document
Purpose
Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST
1) What is changed in 11gR2 regarding to RDBMS DST updates::
2) When is there need to apply RDBMS DST patches to the 11.2.0.x ORACLE_HOM
E before using DBMS_DST?
2a) When updating to a RDBMS DST version higher than DSTv11 in 11.2.0.1
2b) When updating to a RDBMS DST version higher than DSTv14 in 11.2.0.2
3) Checks before doing the actual update of the RDBMS DST version using DBM
S_DST:
3a) check current RDBMS DST version and "DST UPGRADE STATUS".
3b) Check UPFRONT using DBMS_DST if there is affected data that cannot be r
esolved automatically.
4) Do the actual RDBMS DST version update of the database using DBMS_DST:
5) Applying a new RDBMS DST version to 11gR2 clients.
6) How long will DBMS_DST take?
7) Known Issues
References
--------------------------------------------------------------------------------
Applies to:
Oracle Server - Enterprise Edition - Version: 11.2.0.1.0 and later [Release: 1
1.2 and later ]
Purpose
To provide an overview on how to perform a RDBMS DST version update in Oracle RD
BMS 11gR2 and higher. This note is intended to provide a hands on overview in ad
dition to the documentation set section.
If you are Upgrading to 11gR2 please do check first
Note 815679.1 Actions For DST Updates When Upgrading To 11.2.0.1 Base Release
Note 1201253.1 Actions For DST Updates When Upgrading To Or Applying The 11.2.0.
2 Patchset
If you upgrade from an older RDBMS version to 11gR2 the DST version in 11gR2 (SE
LECT version FROM v$timezone_file;) will be simply the same as the DST version t
hat was used in the older RDBMS version.
There are however a few situations where some extra steps are needed, so please
do check above notes before upgrading to 11gR2.
This note does not cover OJVM DST updates for the simple reason that OJVM DST up
dates do not need any action on stored data. They can be simply applied. See the
readme of the OJVM patches for installation instructions.
Oracle RDBMS 11.2.0.1 uses by default DSTv4 for the OJVM. If a higher DST versio
n for the OJVM in 11.2.0.1 is needed please apply the OJVM DSTv13 patch or highe
r.
Oracle RDBMS 11.2.0.2 uses by default DSTv14 for the OJVM.
The RDBMS and OJVM DST versions are NOT technically related so they do not NEED
to be the same.

Oracle cannot say to what DST version you need to use, this simply depends on if
you are using DST information or not in SQL.
See Note 412160.1 section " E) I'm on DSTv <insert current version of your db> ,
do I NEED to apply DST newer patches?" )
If you do use RDBMS DST information in your application then we suggest to apply
the latest RDBMS DST patch available for 11.2.0.x AFTER the upgrade to 11.2 and
update all the 11.2 databases in the 11.2 ORACLE_HOME to that DST version using
DBMS_DST. ( All DST updates are listed in Note 412160.1 )
If you have no idea or not using the RDBMS DST information in your application t
hen we suggest to simply update all the 11.2 databases in the 11.2 ORACLE_HOME t
o the highest RDBMS DST version included by default in version 11.2.0.1 ( =DSTv1
1) or 11.2.0.2 (=DSTv14) using DBMS_DST AFTER the upgrade to 11.2.
Note that:
* DSTv1 to DSTv11 RDBMS DST files are included in the Oracle 11.2.0.1 software i
nstallation, so there are no Oracle 11.2.0.1 RDBMS DST patches for DSTv1 to DSTv
11.
* DSTv1 to DSTv14 RDBMS DST files are included in the Oracle 11.2.0.2 software i
nstallation, so there are no Oracle 11.2.0.2 RDBMS DST patches for DSTv1 to DSTv
14.
Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST
1) What is changed in 11gR2 regarding to RDBMS DST updates::

For Oracle versions 11.2.0.1 and later, it is no longer necessary to use utltzuv
X.sql (utltzuv2.sql, ..., utltzuv13.sql ) scripts in order to apply a RDBMS DST
patch.
Oracle 11.2.0.1 has by default all RDBMS DST updates from DSTv1 to DSTv11 includ
ed in the software installation.
Oracle 11.2.0.2 has by default all RDBMS DST updates from DSTv1 to DSTv14 includ
ed in the software installation.
These files are found in $ORACLE_HOME/oracore/zoneinfo and have a prefix indicat
ing the DST version.
For example timezlrg_4.dat is the DSTv4 "large" file, timezlrg_11.dat is the DST
v11 "large" file.
By default the "Create database" statement uses the highest timezlrg_XX.dat foun
d in the ORACLE_HOME.
The used RDBMS DST version for the "Create database" statement can be defined by
setting explicit the ORA_TZFILE variable (which is by default not set) during t
he "create database" command, aldo there is in real life little need to do so. O
n windows the ORA_TZFILE needs to be set in the registry.
Note that when creating a new 11.2.0.1 database using the standard provided "inc
ludes datafiles" templates in step 2 of the DBCA the new database will always be
using DSTv11 regardless of the to defined ORA_TZFILE variable setting or applie
d RDMBS DST patches to this $ORACLE_HOME seen this is a clone operation of a see
d DSTv11 database, not a real "create database".
In 11.2.0.2 any new database created by the DBCA using the "includes datafiles"
templates in step 2 of the DBCA will be using DSTv14.
After a DST patch is installed in an 11.2 $ORACLE_HOME there are steps who need
to be done to change a existing database to use this newer DST version.
Simply applying the RDBMS DST patch and restarting the database will NOT enable
the new applied RDBMS DST version patch (like it did in pre-11.2 versions).
This allows several databases who are using the same $ORACLE_HOME to each use a
different RDBMS DST version, something that was not possible in pre-11.2 version
s.
This also implies that if one $ORACLE_HOME is used by several databases you need
check and , if needed , update each database.
Note that it is NOT possible to have different OJVM DST patches/version in one $
ORACLE_HOME, the OJVM DST version is always the same for every database using a
certain $ORACLE_HOME and there can only be one OJVM DST patch applied to an $ORA
CLE_HOME.
For more information please see the docset.
2) When is there need to apply RDBMS DST patches to the 11.2.0.x ORACLE_HOME bef
ore using DBMS_DST?
2a) When updating to a RDBMS DST version higher than DSTv11 in 11.2.0.1
If you simply want to update an existing 11.2.0.1 database to the latest DST pat
ch then it's not needed to install all DST patches "in between", for example if
you want to go from DSTv11 to DSTv14 then there is no need to install RDBMS DSTv
13 patch also (but it can be done if you want) only the DSTv14 RDBMS patch is ne
eded.
Locate the latest RDBMS DST patch available in NOTE:412160.1 Updated DST transit
ions and new Time Zones in Oracle Time Zone File patches
Apply the RDBMS DST patch to the $ORACLE_HOME using Opatch, there is no need to
shutdown the database to apply the RDBMS DST patch in 11.2.
Continue in step 3)
If you want to UPGRADE to 11.2.0.1 and the older Oracle version (11.1.0.x , 10.2
.0.x.etc) is using a RDBMS DST version higher than DSTv11 you need to install th
e SAME DST version as the old (11.1.0.x , 10.2.0.x.etc) version on the 11.2.0.1
side.
This is what is said in NOTE:815679.1 Actions For DST Updates When Upgrading To
11.2.0.1 Base Release.
If you want to update the DST version to a higher DST version than used in the o
lder Oracle version (11.1.0.x , 10.2.0.x.etc) then this needs to be done AFTER t
he upgrade.
Some examples:
* if your 9i system is using DSTv2 and you want to go to DSTv11 on 11.2.0.1 you
do NOT need to apply any RDBMS DST 11.2.0.1 patches seen both DSTv2 and DSTv11 a
re included by default in 11.2.0.1. After the upgrade the 11.2.0.1 database will
then be DSTv2 (= same as 9i ) and then, after the upgrade, you can update the D
ST version from DSTv2 to DSTv11 using step 3) in this note.
* if your 10.1 system is using DSTv4 and you want to go to DSTv14 on 11.2.0.1 yo
u do need to apply the RDBMS DSTv14 11.2.0.1 patch only seen DSTv4 is included b
y default in 11.2.0.1 , but DSTv14 not. After the upgrade the 11.2.0.1 database
will then be DSTv4 (= same as 10.1 ) and then, after the upgrade, you can update
the DST version from DSTv4 to DSTv14 using step 3) in this note.
* if your 10.2 system is using DSTv13 and you want to go to DSTv14 on 11.2.0.1 y
ou need to apply both RDBMS DSTv13 and RDBMS DSTv14 11.2.0.1 patches. After the
upgrade the 11.2.0.1 database will then be DSTv13 (= same as 10.2) and then, aft
er the upgrade, you can update the DST version from DSTv13 to DSTv14 using step
3) in this note.
2b) When updating to a RDBMS DST version higher than DSTv14 in 11.2.0.2
Locate the latest RDBMS DST patch (currently DSTv15) available in NOTE:412160.1
Updated DST transitions and new Time Zones in Oracle Time Zone File patches
Apply the RDBMS DST patch to the ORACLE_HOME using Opatch, there is no need to s
hutdown the database to apply the RDBMS DST patch in 11.2.
Continue in step 3)
If you want to UPGRADE to 11.2.0.2 and the older Oracle version (11.1.0.x , 10.2
.0.x.etc) is using a RDBMS DST version higher than DSTv14 you need to install th
e SAME DST version as the old (11.1.0.x , 10.2.0.x.etc) version on the 11.2.0.2
side.
This is what is said in Note 1201253.1 Actions For DST Updates When Upgrading To
Or Applying The 11.2.0.2 Patchset .
If you want to update the DST version to a higher DST version than the older Ora
cle version (11.1.0.x , 10.2.0.x.etc) then this needs to be done AFTER the upgra
de.
Some examples:
* if your 9i system is using DSTv2 and you want to go to DSTv14 on 11.2.0.2 you
do NOT need to apply any RDBMS DST 11.2.0.2 patches seen both DSTv2 and DSTv14 a
re included by default in 11.2.0.2. After the upgrade the 11.2.0.2 database will
then be DSTv2 (= same as 9i ) and then, after the upgrade, you can update the D
ST version from DSTv2 to DSTv14 using step 3) in this note.
* if your 10.1 system is using DSTv4 and you want to go to DSTv15 on 11.2.0.2 yo
u do need to apply the RDBMS DSTv15 11.2.0.2 patch only seen DSTv4 is included b
y default in 11.2.0.2 , but DSTv15 not. After the upgrade the 11.2.0.2 database
will then be DSTv4 (= same as 10.1 ) and then, after the upgrade, you can update
the DST version from DSTv4 to DSTv15 using step3) in this note.
3) Checks before doing the actual update of the RDBMS DST version using DBMS_DST
:
Note: the next steps use <the new DST version number> in the statements, simply
replace it with the actual number ( 11, 15 etc) of the RDBMS DST version you wan
t to update to.
Please note that his is a DATABASE operation, so it needs to be done for each da
tabase you want to update, even if they use the same ORACLE_HOME.
If needed, make sure the required RDBMS DST patch(es) is/are applied (= step 2 i
n this note was followed).
3a) check current RDBMS DST version and "DST UPGRADE STATUS".
conn / as sysdba
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;
-- check that the output gives
-- PROPERTY_NAME VALUE
-- ------------------------------ ------------------------------
-- DST_PRIMARY_TT_VERSION <the old DST version number>
-- DST_SECONDARY_TT_VERSION 0
-- DST_UPGRADE_STATE NONE
-- DST_PRIMARY_TT_VERSION should match the value found when selecting
SELECT version FROM v$timezone_file;
3b) Check UPFRONT using DBMS_DST if there is affected data that cannot be resolv
ed automatically.
Note that this can be done on a working, live database. Of course it might that
there is data added between this session and the actual upgrade of the RDBMS DST
version that is affected. This is especially plausible if the update is done cl
ose to a DST change in your timezone and this timezone is affected by this RDBMS
DST update.
The steps in this point will NOT update any data , it's pure "check" faze using
DBMS_DST.
conn / as sysdba
-- start prepare window
-- these steps will NOT update any data yet.
-- this might speed up DBMS_DST on some db's
-- see Bug 10209691
alter session set "_with_subquery"=materialize;
exec DBMS_DST.BEGIN_PREPARE(<the new DST version number>)
Sample error if the 11.2 DST patch for the requested DST version is not installe
d:
SQL> exec DBMS_DST.BEGIN_PREPARE(13)
*
ERROR at line 1:
ORA-30094: failed to find the time zone data file for version 13 in
$ORACLE_HOME/oracore/zoneinfo
FIX: install the 11.2 patch for the DST version you want to use. See note 412160
.1
Sample error if the requested new DST version is the current or a lower than the
current timezone version:
*
ERROR at line 1:
ORA-56921: invalid time zone version
FIX: you cannot "downgrade" DST, there is no need to do this. The new DST versio
n needs to be higher than the current DST_PRIMARY_TT_VERSION
-- check for prepare status

-- output should be
-- ------------------------------ ------------------------------
-- DST_SECONDARY_TT_VERSION <the new DST version number>
-- DST_UPGRADE_STATE PREPARE
-- truncate logging tables if they exist.
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;
-- log affected data
set serveroutput on
BEGIN
DBMS_DST.FIND_AFFECTED_TABLES
(affected_tables => 'sys.dst$affected_tables',
log_errors => TRUE,
log_errors_table => 'sys.dst$error_table');
END;
/
-- check what tables have affected data that cannot be resolved automatically.
-- if this gives no rows then there is no problem at all
SELECT * FROM sys.dst$affected_tables;
-- IF previous select gives rows then you can see
-- what kind of problem there are in those rows
SELECT * FROM sys.dst$error_table;
-- error_on_overlap_time is error number ORA-1883
-- error_on_nonexisting_time is error number ORA-1878
-- for a explanation of the reported data please see
-- "Error Handling when Upgrading Time Zone File and Timestamp with Time Zone Da
ta"
-- For the "error_on_overlap_time" and "error_on_nonexisting_time" you do not HA
VE to
-- take action on this data to upgrade the DST version, but it is advised
-- to at least to check the results AFTER the update.
-- all "error_on_overlap_time" rows
SELECT * FROM sys.dst$error_table where ERROR_NUMBER= '1883';
-- all "error_on_nonexisting_time" rows
SELECT * FROM sys.dst$error_table where ERROR_NUMBER= '1878';
-- check for all other possible problems
SELECT * FROM sys.dst$error_table where ERROR_NUMBER not in ('1878','1883');
When updating from DSTv1 or DSTv2 (mainly after 9.2 upgrades) to a higher DST ve
rsion it is possible to have also '1882' errors.
The cause is explained in Note 414590.1. These can be ignored, they will be corr
ected during the actual update of the dst version.
-- end prepare window, the rows above will stay in those tables.
EXEC DBMS_DST.END_PREPARE;
-- check if this is ended
-- output should be
-- ---------------------------- ------------------------------
Assuming all non-existing time and overlap times in previous step are solved or
logged, so using for
DBMS_DST.UPGRADE_DATABASE error_on_overlap_time => FALSE and error_on_nonexisti
ng_time => FALSE);
For RAC the database should be in single instance mode , as required by the "sta
rtup UPGRADE".
conn / as sysdba
shutdown immediate;
startup upgrade;
set serveroutput on
-- check if previous prepare window is ended
-- output should be
-- ---------------------------- ------------------------------
-- If DST_UPGRADE_STATE is "PREPARE" then you did not ended
-- the prepare window in step 3)
-- If there are objects containing TSTZ data in recycle bin, please purge the bi
n now.
-- Otherwise dbms_dst.begin_upgrade will report "ORA-38301: Can not perform DDL/
DML over objects in Recycle Bin".
purge dba_recyclebin;
-- clean used tables
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;

-- see Bug 10209691
-- start upgrade window
EXEC DBMS_DST.BEGIN_UPGRADE(<the new DST version number>);
-- the message
-- "An upgrade window has been successfully started."
-- will be seen
Sample error if a previous (prepare) window was not ended:

SQL> EXEC DBMS_DST.BEGIN_UPGRADE(11);
BEGIN DBMS_DST.BEGIN_UPGRADE(11); END;
*
ERROR at line 1:
ORA-56920: a prepare or upgrade window or an on-demand or datapump-job loading
of a secondary time zone data file is in an active state
FIX: You NEED to end the "PREPARE" window in the previous step BEFORE doing the
UPGRADE.
Or in other words, you did not do the "EXEC DBMS_DST.END_PREPARE;" step in point
3)
Sample error if the requested DST version / patch is not installed:
*
ERROR at line 1:
ORA-30094: failed to find the time zone data file for version 13 in
$ORACLE_HOME/oracore/zoneinfo
FIX: Install the 11.2 patch for the DST version you want to use. See note 412160
.1
Sample error if the database is not in upgrade mode:
*
ERROR at line 1:
ORA-56926: database must be in UPGRADE mode in order to start an upgrade windo
FIX: start the database in UPGRADE mode
-- check if this select

-- gives this output:
-- --------------------------- ------------------------------
-- DST_PRIMARY_TT_VERSION <the new DST version number>
-- DST_SECONDARY_TT_VERSION <the old DST version number>
-- DST_UPGRADE_STATE UPGRADE
-- you can check what tables need to updated using
SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE
_IN_PROGRESS='YES';
-- restart the database
shutdown immediate
startup

-- see Bug 10209691
-- now upgrade the tables who need action
set serveroutput on
VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel => TRUE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
error_on_overlap_time => FALSE,
error_on_nonexisting_time => FALSE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
-- ouput of this will be a list of tables lie:
-- Table list: SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S
-- Number of failures: 0
-- ....
-- Table list: SYSMAN.MGMT_PROV_ASSIGNMENT
-- Table list: SYSMAN.MGMT_CONFIG_ACTIVITIES
-- Failures:0
-- if there where no failures then end the upgrade.
VAR fail number
BEGIN
DBMS_DST.END_UPGRADE(:fail);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :fail);
END;
/
Sample error if DBMS_DST.UPGRADE_DATABASE was not issued:

ERROR at line 1:
ORA-56929: Ending an upgrade window failed
FIX: start database normally and run DBMS_DST.UPGRADE_DATABASE
-- output that will be seen:

-- An upgrade window has been successfully ended.
-- Failures:0
-- last checks
-- needed output:
-- ---------------------------- ------------------------------
SELECT * FROM v$timezone_file;

-- needed output:
-- FILENAME VERSION
-- ------------------ ----------
-- timezlrg_<new version>.dat <new version>
If needed, start over for the next database in the same ORACLE_HOME.
5) Applying a new RDBMS DST version to 11gR2 clients.

For an Oracle client simply apply the RDBMS DST patch using Opatch.
Oracle 11gR2 Clients will use the highest timezlrg_XX.dat found in the ORACLE_HO
ME.
This can be overwritten by setting explicit the ORA_TZFILE variable (which is by
default not set), aldo there is in real life little need to do so.
A DSTv13 11.2.0.1 client can perfectly connect to an non-DSTv13 server for examp
le. The DST version only comes to play when actually using DST related informati
on in SQL.
6) How long will DBMS_DST take?

This mainly depends on the amount of TSTZ data you have in your database
This select will give a count(*) of all tables that have TSTZ column (= processe
d by dbsm_dst)
conn / as sysdba
set serveroutput on
DECLARE
countstar NUMBER;
stmt VARCHAR2(1000);
BEGIN
FOR rec in
( select distinct c.owner, c.table_name
where c.data_type like '%WITH TIME ZONE'
and c.owner=o.owner
order by c.owner, c.table_name)
LOOP
stmt := 'select count(*) from "' || rec.owner || '"."' || rec.table_name || '"'
;
execute immediate stmt into countstar;
DBMS_OUTPUT.PUT_LINE(rec.owner||'.'|| rec.table_name|| ' - count * is : ' || cou
ntstar );
END LOOP;
END;
/
For most databases this will be Dbms_scheduler job logs, by default they are pur
ged after 30 day's.
If needed you can remove job data that is not needed any more, but sometimes thi
s does not work: Note 749440.1 Dbms_scheduler.Purge Not Removing Entries from db
a_scheduler_job_run_details
7) Known Issues
* DBMS_DST is very slow on some databases
Bug 10209691 SLOW PERFORMANCE ON ALL_TSTZ_TAB_COLS
Not fixed yet
Workaround: use "alter session set "_with_subquery"=materialize;" in the session
running DBMS_DST
* DBMS_DST fails on some case insensitive table or column names with ORA-00904:
invalid identifier or ORA-01747: invalid user.table.column, table.column, or col
umn specification.
This is fixed in 11.2.0.2
To see if you have possible affected objects :
select owner, table_name, column_name from dba_tab_columns where data_type like

'TIMESTAMP% WITH TIME ZONE' and ( upper(table_name) != table_name or upper(colum
n_name) != column_name);
Workaround (for 11.2.0.1): rename the column(s) to a non-Case insensitive name a
nd then rename them back after wards using ALTER TABLE ... RENAME COLUMN .. TO .
.; and/or the table name using ALTER TABLE ... RENAME TO ...;
References
NOTE:1201253.1 - Actions For DST Updates When Upgrading To Or Applying The 11.2.
0.2 Patchset
NOTE:1255474.1 - Different Time Zone Version In Registry$Database And V$Timezone
_file
ile patches
NOTE:815679.1 - Actions For DST Updates When Upgrading To 11.2.0.1 Base Release
############################################
RESULTS FROM RMCT DST 14 UPGRADE - 4/26/2011
############################################
stlpr331> sqlplus /@rmct

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Apr 26 11:01:00 2011
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> set pagesize 2000
VERSION
----------
4
SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
2 FROM DATABASE_PROPERTIES
3 WHERE PROPERTY_NAME LIKE 'DST_%'
4 ORDER BY PROPERTY_NAME;
PROPERTY_NAME VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION 4
DST_SECONDARY_TT_VERSION 0
DST_UPGRADE_STATE NONE
PROPERTY_NAME VALUE
------------------------------ ------------------------------
DST_UPGRADE_STATE PREPARE
SQL> TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;

Table truncated.
SQL> TRUNCATE TABLE sys.dst$affected_tables;
Table truncated.
SQL> TRUNCATE TABLE sys.dst$error_table;
Table truncated.
SQL> set serveroutput on

SQL> BEGIN
2 DBMS_DST.FIND_AFFECTED_TABLES
3 (affected_tables => 'sys.dst$affected_tables',
4 log_errors => TRUE,
5 log_errors_table => 'sys.dst$error_table');
6 END;
7 /
-- check what tables have affected data that cannot be resolved automatically.
-- if this gives no rows then there is no problem at all
SQL> SELECT * FROM sys.dst$affected_tables;

TABLE_OWNER TABLE_NAME
------------------------------ ------------------------------
COLUMN_NAME
--------------------------------------------------------------------------------
ROW_COUNT ERROR_COUNT
---------- -----------
SYS SCHEDULER$_JOB
LAST_START_DATE
1 1
SYS SCHEDULER$_JOB
LAST_END_DATE
1 1
------------------------------ ------------------------------
COLUMN_NAME
--------------------------------------------------------------------------------
---------- -----------
SYS SCHEDULER$_JOB
NEXT_RUN_DATE
1 1
SYS SCHEDULER$_JOB
START_DATE
------------------------------ ------------------------------
COLUMN_NAME
--------------------------------------------------------------------------------
---------- -----------
1 1
SYS SCHEDULER$_JOB
LAST_ENABLED_TIME
1 1
SYS SCHEDULER$_JOB_RUN_DETAILS
------------------------------ ------------------------------
COLUMN_NAME
--------------------------------------------------------------------------------
---------- -----------
REQ_START_DATE
29 29
SYS SCHEDULER$_JOB_RUN_DETAILS
START_DATE
29 29
7 rows selected.
-- IF previous select gives rows then you can see

-- what kind of problem there are in those rows
SQL> SELECT * FROM sys.dst$error_table;

TABLE_ TABLE_NAME COLUMN_NAME RID ER
ROR_NUMBER
------ ------------------------------ ------------------ -------------------- --
----------
SYS SCHEDULER$_JOB LAST_START_DATE AAAMN5AABAAAf7qAAA
1882
SYS SCHEDULER$_JOB LAST_END_DATE AAAMN5AABAAAf7qAAA
1882
SYS SCHEDULER$_JOB NEXT_RUN_DATE AAAMN5AABAAAf7qAAA
1882
SYS SCHEDULER$_JOB START_DATE AAAMN5AABAAAf7qAAA
1882
SYS SCHEDULER$_JOB LAST_ENABLED_TIME AAAMN5AABAAAf7qAAA
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAAXUAAT
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAAXUAAW
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAAXUAAZ
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZpAAE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZpAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZpAAy
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAAM
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAAg
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAAm
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAAv
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAA1
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtAA9
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtABE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZtABM
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZuAAx
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZuAA8
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZuABJ
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAAH
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAAf
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAAm
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAAt
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAA1
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvAA8
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZvABE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZwAAe
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZwAAo
1882
SYS SCHEDULER$_JOB_RUN_DETAILS REQ_START_DATE AAAMOXAAHAAAEZwAA7
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAAXUAAT
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAAXUAAW
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAAXUAAZ
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZpAAE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZpAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZpAAy
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAAM
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAAg
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAAm
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAAv
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAA1
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtAA9
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtABE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZtABM
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZuAAx
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZuAA8
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZuABJ
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAAH
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAAU
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAAf
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAAm
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAAt
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAA1
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvAA8
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZvABE
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZwAAe
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZwAAo
1882
SYS SCHEDULER$_JOB_RUN_DETAILS START_DATE AAAMOXAAHAAAEZwAA7
1882
63 rows selected.
When updating from DSTv1 or DSTv2 (mainly after 9.2 upgrades) to a higher DST ve
rsion it is possible to have also '1882' errors.
The cause is explained in Note 414590.1. These can be ignored, they will be corr
ected during the actual update of the dst version.
-- end prepare window, the rows above will stay in those tables.
EXEC DBMS_DST.END_PREPARE;
SQL> EXEC DBMS_DST.END_PREPARE;

A prepare window has been successfully ended.
-- check if this is ended

PROPERTY_NAME VALUE
------------------------------ ------------------------------
Assuming all non-existing time and overlap times in previous step are solved or
logged, so using for
DBMS_DST.UPGRADE_DATABASE error_on_overlap_time => FALSE and error_on_nonexisti
ng_time => FALSE);
For RAC the database should be in single instance mode , as required by the "sta
rtup UPGRADE".
-- check if this select

-- gives this output:
-- --------------------------- ------------------------------
-- DST_SECONDARY_TT_VERSION <the old DST version number>
-- DST_UPGRADE_STATE UPGRADE

PROPERTY_NAME VALUE
------------------------------ ------------------------------
DST_UPGRADE_STATE UPGRADE

SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE
_IN_PROGRESS='YES';
SQL> SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UP

GRADE_IN_PROGRESS='YES';
OWNER TABLE_NAME UPG
------------------------------ ------------------------------ ---
SYSMAN AQ$_MGMT_LOADER_QTABLE_L YES
SYSMAN AQ$_MGMT_LOADER_QTABLE_S YES
SYSMAN AQ$_MGMT_NOTIFY_QTABLE_L YES
SYSMAN AQ$_MGMT_NOTIFY_QTABLE_S YES
SYSMAN MGMT_PROV_NET_CONFIG YES
SYSMAN MGMT_PROV_OPERATION YES
SYSMAN MGMT_PROV_RPM_REP YES
SYSMAN MGMT_PROV_STAGING_DIRS YES
SYSMAN MGMT_PROV_SUITE_INST_MEMBERS YES
SYSMAN MGMT_PROV_ASSIGNMENT YES
SYSMAN MGMT_PROV_BOOTSERVER YES
SYSMAN MGMT_PROV_CLUSTER_NODES YES
SYSMAN MGMT_PROV_DEFAULT_IMAGE YES
SYSMAN MGMT_PROV_IP_RANGE YES
14 rows selected.
SQL> shutdown immediate;

Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 1044193280 bytes
Fixed Size 2164920 bytes
Variable Size 276830024 bytes
Database Buffers 759169024 bytes
Redo Buffers 6029312 bytes
Database mounted.
Database opened.
SQL>
-- see Bug 10209691
-- now upgrade the tables who need action
set serveroutput on
VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel => TRUE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
error_on_overlap_time => FALSE,
error_on_nonexisting_time => FALSE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
Table list: "SYSMAN"."MGMT_PROV_IP_RANGE"

Number of failures: 0
Table list: "SYSMAN"."MGMT_PROV_DEFAULT_IMAGE"
Table list: "SYSMAN"."MGMT_PROV_CLUSTER_NODES"
Table list: "SYSMAN"."MGMT_PROV_BOOTSERVER"
Table list: "SYSMAN"."MGMT_PROV_ASSIGNMENT"
Table list: "SYSMAN"."MGMT_PROV_SUITE_INST_MEMBERS"
Table list: "SYSMAN"."MGMT_PROV_STAGING_DIRS"
Table list: "SYSMAN"."MGMT_PROV_RPM_REP"
Table list: "SYSMAN"."MGMT_PROV_OPERATION"
Table list: "SYSMAN"."MGMT_PROV_NET_CONFIG"
Table list: "SYSMAN"."AQ$_MGMT_NOTIFY_QTABLE_S"
Table list: "SYSMAN"."AQ$_MGMT_NOTIFY_QTABLE_L"
Table list: "SYSMAN"."AQ$_MGMT_LOADER_QTABLE_S"
Table list: "SYSMAN"."AQ$_MGMT_LOADER_QTABLE_L"
Failures:0
-- ouput of this will be a list of tables lie:

-- Table list: SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S
-- ....
-- Table list: SYSMAN.MGMT_PROV_ASSIGNMENT
-- Table list: SYSMAN.MGMT_CONFIG_ACTIVITIES
-- Failures:0
-- if there where no failures then end the upgrade.
VAR fail number

BEGIN
DBMS_DST.END_UPGRADE(:fail);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :fail);
END;
/
SQL> VAR fail number

SQL> BEGIN
2 DBMS_DST.END_UPGRADE(:fail);
3 DBMS_OUTPUT.PUT_LINE('Failures:'|| :fail);
4 END;
5 /
An upgrade window has been successfully ended.
Failures:0

-- needed output:
-- ---------------------------- ------------------------------
SELECT * FROM v$timezone_file;

-- needed output:
-- FILENAME VERSION
-- ------------------ ----------
-- timezlrg_<new version>.dat <new version>

PROPERTY_NAME VALUE
------------------------------ ------------------------------
SQL> SELECT * FROM v$timezone_file;
FILENAME VERSION
-------------------- ----------
timezlrg_14.dat 14

DSTv15 Update For Oracle 11gR2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DSTv15 Update For Oracle 11gR2

Uploaded by

Copyright:

Available Formats

Applying the DSTv15 update for the Oracle Database (Doc ID 1274498.

Compared to DSTv14 this is the list of updated timezones:

Africa/Cairo, Egypt , America/Bahia_Banderas, Asia/Amman, Asia/Gaza, Europe/Hel

Scope and Application

Applying the DSTv15 update for the Oracle Database

SQL> conn / as sysdba

select c.owner || '.' || c.table_name || '(' || c.column_name || ') -'

SQL> conn / as sysdba

SQL> conn / as sysdba

For Unix platforms

Cd to patch 10406470 directory

Step5 : shutdown the database: SQL> shutdown

Modified Date LabelModifiedModified Date01-APR-2011Document Type LabelTypeDocu

Scope and Application

Applying the DSTv14 update for the Oracle Database

SQL> conn / as sysdba

select c.owner || '.' || c.table_name || '(' || c.column_name || ') -'

SQL> conn / as sysdba

SQL> conn / as sysdba

For Unix platforms

Cd to patch 9751299 directory

Step1: If needed, edit init.ora and set cluster_database=FALSE

Step5 : shutdown the database: SQL> shutdown

Modified Date LabelModifiedModified Date15-MAR-2011Document Type LabelTypeDocu

Scope and Application

1) What is changed in 11gR2 regarding to RDBMS DST updates::

-- check for prepare status

-- this might speed up DBMS_DST on some db's

Sample error if a previous (prepare) window was not ended:

-- check if this select

-- this might speed up DBMS_DST on some db's

Sample error if DBMS_DST.UPGRADE_DATABASE was not issued:

-- output that will be seen:

SELECT * FROM v$timezone_file;

5) Applying a new RDBMS DST version to 11gR2 clients.

6) How long will DBMS_DST take?

select owner, table_name, column_name from dba_tab_columns where data_type like

stlpr331> sqlplus /@rmct

SQL> TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;

SQL> set serveroutput on

SQL> SELECT * FROM sys.dst$affected_tables;

-- IF previous select gives rows then you can see

SQL> SELECT * FROM sys.dst$error_table;

SQL> EXEC DBMS_DST.END_PREPARE;

-- check if this is ended

-- check if this select

SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value

-- you can check what tables need to updated using

SQL> SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UP

SQL> shutdown immediate;

Table list: "SYSMAN"."MGMT_PROV_IP_RANGE"

-- ouput of this will be a list of tables lie:

VAR fail number

SQL> VAR fail number

SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value

SELECT * FROM v$timezone_file;

SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value

You might also like