updating the rdbms dst version in 11g release 2 (11.2.0.1 and up) using dbms_dst [id 977512.1]

Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST [ID 977512.1]

In this Document

PurposeDetails

1) What is changed in 11gR2 about RDBMS DST updates (when compared to 11gR1 and lower):2) When do I need to apply RDBMS DST patches to the 11.2.0.x ORACLE_HOME before using DBMS_DST (= before going to step 3) in this note)?2a) 11.2.0.1 : When updating to a RDBMS DST version higher than DSTv112b) 11.2.0.2 and 11.2.0.3: When updating to a RDBMS DST version higher than DSTv143) Checks before doing the actual update of the RDBMS DST version using DBMS_DST in an 11.2.0.x database:3a) check current RDBMS DST version and "DST UPGRADE STATUS" in your 11.2.0.x database.3b) Check UPFRONT using DBMS_DST if there is affected data that cannot be resolved automatically in your 11.2.0.x database.4) Do the actual RDBMS DST version update of the database using DBMS_DST in your 11.2.0.x database:5) Applying a new RDBMS DST version to 11gR2 clients.6) How long will DBMS_DST take?7) Known Issues with DBMS_DST in 11.2.0.x:

* an ORA-54017: UPDATE operation disallowed on virtual columns error is seen during DBMS_DST.UPGRADE_DATABASE :* 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 column specification.* if DBMS_DST.BEGIN_PREPARE fails with ORA-00907: missing right parenthesis* if DBMS_DST.FIND_AFFECTED_TABLES fails with ORA-00907: missing right parenthesis

* if DBMS_DST.FIND_AFFECTED_TABLES fails with ORA-00904: "T"."SYS_C00001_-random number here-": invalid identifier* if DBMS_DST.BEGIN_PREPARE fail with ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.* DBMS_DST is very slow on some databases* if the database is still in DST upgrade mode then select from timestamp with timezone columns will give the data without the second fractions* EXEC DBMS_DST.BEGIN_PREPARE (or any other DBMS_DST call) fails with 'PLS-00201: identifier 'DBMS_DST.-insert name here-' must be declared':

8) Can the DST version be updated in 11.2.0.x without downtime? Or in a "rolling" fashion on RAC?

References

Applies to:

Oracle Database - Standard Edition - Version 11.2.0.1 to 11.2.0.4 [Release 11.2]Oracle Database - Enterprise Edition - Version 11.2.0.1 to 11.2.0.4 [Release 11.2]Information in this document applies to any platform.

Purpose

To provide an overview on how to perform a RDBMS DST version update in Oracle RDBMS 11gR2. This note is intended to provide a hands on overview in addition to the documentation set section.

This note does not cover OJVM DST updates for the simple reason that OJVM DST updates 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 version for the OJVM in 11.2.0.1 is needed please apply the OJVM DSTv13 patch or higher. Oracle RDBMS 11.2.0.2 uses by default DSTv14 for the OJVM.Oracle RDBMS 11.2.0.3 uses by default DSTv16 for the OJVM.The RDBMS and OJVM DST versions are NOT technically related so they do not NEED to be the same.

Details

For Oracle RDBMs 12cR1 please see note 1509653.1 Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST

If you are upgrading from an older Oracle Version please do check before doing the Oracle RDBMS version upgradeNote 815679.1 Actions For DST Updates When Upgrading To 11.2.0.1 Base ReleaseNote 1201253.1 Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 Patchset Note 1358166.1 Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3 Patchset

Summary of above notes in a nutshell: After an upgrade from an older RDBMS version to 11gR2 the RDBMS DST version (=SELECT version FROM v$timezone_file;) after the Oracle version upgrade to 11gR2 will be simply the same as the DST version that was used in the older RDBMS version.This also implies that:

There is no need to apply "DST patches" to the OLD version (11.1.0.x , 10.2.0.x. etc) home before doing the version upgrade to 11gR2.

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 the SAME DST version as the old (11.1.0.x , 10.2.0.x.etc) version on the 11.2.0.1 side before the version upgrade.

If you want to upgrade to 11.2.0.2 or 11.2.0.3 and the older Oracle version (11.2.0.x, 11.1.0.x , 10.2.0.x. etc) is using a RDBMS DST version higher than DSTv14 you need to install the SAME DST version as the old (11.2.0.x, 11.1.0.x , 10.2.0.x.etc) version on the 11.2.0.2 / 11.2.0.3 side before the version upgrade .

After the Oracle version upgrade to 11.2.0.x DBMS_DST can then be used to do an upgrade of the RDBMS DST version of the 11gR2 database. There are however a few situations where some extra steps are needed before doing the version upgrade, so please do check above notes before upgrading to 11gR2.

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?" )

1) What is changed in 11gR2 about RDBMS DST updates (when compared to 11gR1 and lower):

This is information about the changes in 11.2 and is applicable to 11.2 and higher.

For Oracle versions 11.2.0.1 and later, it's no longer necessary to use utltzuvX.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 included in the software installation.



These files are found in $ORACLE_HOME/oracore/zoneinfo and have a prefix indicating the DST version.For example timezlrg_4.dat is the DSTv4 "large" file, timezlrg_11.dat is the DSTv11 "large" file.

In 11.2 and up there are no timezlrg.dat and timezone.dat, this is normal and intended.Do NOT make any symbolic links for timezlrg.dat and timezone.dat or copy any of the files in \oracore\zoneinfo\ and rename them to timezlrg.dat and timezone.datin 11.2 and up there should be NO timezlrg.dat and timezone.dat in $ORACLE_HOME/oracore/zoneinfo/ (unix) or %ORACLE_HOME%\oracore\zoneinfo\ (windows)

By default the "Create database" statement uses the highest timezlrg_XX.dat found 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 the "create database" command, aldo there is in real life little need to do so. On 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 "includes 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 applied RDMBS DST patches to this $ORACLE_HOME seen this is a clone operation of a seed DSTv11 database, not a real "create database".In 11.2.0.2 or 11.2.0.3 any new database created by the DBCA using the "includes datafiles" templates in step 2 of the DBCA will be using DSTv14.

From version 11.2.0.1 onwards the used RDBMS DST version is a database level configuration.

After a DST patch is installed in an 11.2.0.x $ORACLE_HOME there are steps who need to be done to change an 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 versions.This also implies that if one $ORACLE_HOME is used by several databases you need check and , if needed , update each database.

So it is perfectly possible (and supported) to have for example * a DSTv4 (or any other RDBMS DST version) 11.2.0.1/11.2.0.3/etc database* a DSTv4 11.2.0.3 database and a DSTv14 11.2.0.3 using the same ORACLE_HOME. We recommend in general to update 11.2.0.x databases to at least to the highest RDBMS DST version included by default in the Oracle 11gR2 version. This is for 11.2.0.1 DSTv11 , for 11.2.0.2 DSTv14 and for 11.2.0.3 DSTv14.There are however situations where it makes perfect sence to use an older RDBMS DST version for an 11.2.0.x database, one such example is when using transportable tablespaces and for one of the 2 sides the RDBMS dst version cannot be updated (for whatever reason).

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 $ORACLE_HOME.

For more information please see the docset.

2) When do I need to apply RDBMS DST patches to the 11.2.0.x ORACLE_HOME before using DBMS_DST (= before going to step 3) in this note)?

When you want to update an 11.2 database in the 11.2 ORACLE_HOME to the highest RDBMS DST version included by default in that 11gR2 version then there is no need to apply any "DST patch".This is for 11.2.0.1 DSTv11 , for 11.2.0.2 DSTv14 and for 11.2.0.3 DSTv14.

So if you want to update:

an Oracle 11.2.0.1 RDBMS to DSTv11 then simply go to step 3a) and use 11 as <the new DST version number> in the statements, DSTv1 to DSTv11 RDBMS DST files are included in the Oracle 11.2.0.1 software

installation, so there are no Oracle 11.2.0.1 RDBMS DST patches for DSTv1 to DSTv11.

an Oracle 11.2.0.2 RDBMS to DSTv14 then simply go to step 3a) and use 14 as <the new DST version number> in the statements, DSTv1 to DSTv14 RDBMS DST files are included in the Oracle 11.2.0.2 software installation, so there are no Oracle 11.2.0.2 RDBMS DST patches for DSTv1 to DSTv14.

an Oracle 11.2.0.3 RDBMS to DSTv14 then simply go to step 3a) and use 14 as <the new DST version number> in the statements, DSTv1 to DSTv14 RDBMS DST files are included in the Oracle 11.2.0.3 software installation, so there are no Oracle 11.2.0.3 RDBMS DST patches for DSTv1 to DSTv14.

If you want to update the DST version of an EXISITING (= no update of the Oracle version) 11.2.0.x installation/database to a higher DST version than 11 or 14 see point 2a) or 2b) (depending on the version)

2a) 11.2.0.1 : When updating to a RDBMS DST version higher than DSTv11

If you want to update an existing 11.2.0.1 database to the latest DST patch then it's not needed to install all DST patches "in between", for example if you want to go from DSTv11 to DSTv16 then there is no need to install RDBMS DSTv12, 13, 14 and 15 patches also (but it can be done if you want) only the DSTv16 RDBMS patch is needed.

Locate the latest RDBMS DST patch for 11.2.0.1 (this is DSTv16 patch 12320006). All the RDBMS DST update notes are available in NOTE:412160.1 Updated DST transitions and new Time Zones in Oracle Time Zone File patchesApply 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)

2b) 11.2.0.2 and 11.2.0.3: When updating to a RDBMS DST version higher than DSTv14

If you want to update an existing 11.2.0.2 or 11.2.0.3 database to the latest DST patch then it's not needed to install all DST patches "in between", for example if you want to go from DSTv14 to DSTv19 then there is no need to install RDBMS DSTv15, 16, 17 and 18 patches also (but it can be done if you want) only the DSTv19 RDBMS patch is needed.

Locate the latest RDBMS DST patch (this is currently DSTv19 patch 15897859 ). All the RDBMS DST update notes are available in NOTE:412160.1 Updated DST transitions and new Time Zones in Oracle Time

Zone File patchesApply 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)

3) Checks before doing the actual update of the RDBMS DST version using DBMS_DST in an 11.2.0.x database:

If needed, make sure the required RDBMS DST patch(es) is/are applied (= step 2 in this note was followed).

The actual DST update itself is done in step 4) of this note.

3a) check current RDBMS DST version and "DST UPGRADE STATUS" in your 11.2.0.x database.

conn / as sysdbaSELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) valueFROM DATABASE_PROPERTIESWHERE 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 <<<<------ THIS NEEDS TO BE "0" !!!-- DST_UPGRADE_STATE NONE <<<<------ THIS NEEDS TO BE "NONE" !!!

-- DST_PRIMARY_TT_VERSION should match the value found when selecting

SELECT version FROM v$timezone_file;

If DST_PRIMARY_TT_VERSION is <the old DST version number>, DST_SECONDARY_TT_VERSION is 0 and DST_UPGRADE_STATE is NONE go to 3b)

If DST_UPGRADE_STATE is UPGRADE, PREPARE or DATAPUMP then "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" erros will be seen in the next steps.

solving DST_UPGRADE_STATE in UPGRADE, PREPARE or DATAPUMP status:

* if DST_UPGRADE_STATE is "DATAPUMP" then simply wait until the datapump load is done or check Note 336014.1 How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ?

* if DST_UPGRADE_STATE is "PREPARE" then execute an EXEC DBMS_DST.END_PREPARE; , check that DST_UPGRADE_STATE is NONE and go to go to 3b)* if DST_UPGRADE_STATE is "UPGRADE" then an upgrade is already in progress, check if an other DBA is doing a upgrade, if not then go to step 4), skip the truncate and EXEC DBMS_DST.BEGIN_UPGRADE steps (!) in step 4 and do the steps after that.

Note: Also check that ORA_TZFILE is NOT set in the environment of your 11.2.0.x database to $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat or $ORACLE_HOME/oracore/zoneinfo/timezone.dat , if it is set then remove this from your 11.2.0.x home settings and restart the database and listener.

3b) Check UPFRONT using DBMS_DST if there is affected data that cannot be resolved automatically in your 11.2.0.x database.

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 want to update to.* This is a DATABASE operation, so it needs to be done for each database you want to update, even if they use the same ORACLE_HOME.* The steps in point 3b) 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 close to a DST change in your timezone and this timezone is affected by this RDBMS DST update.* The steps in this point 3b) will NOT update any data and NOT update the DST version , it's a pure "check" faze using DBMS_DST. To upgrade the DST version you ALSO need to do step 4) Do the actual RDBMS DST version update of the database using DBMS_DST: in this note.

-- the actual commands are listed in BOLD-- 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 want to update to.

conn / as sysdba-- If there are objects containing TSTZ data in recycle bin, -- please purge the bin now.

purge dba_recyclebin;

-- this alter session might speed up DBMS_DST on some db's-- see Bug 10209691 / Bug 12658443

alter session set "_with_subquery"=materialize;

-- to avoid the issue in note 1407273.1

alter session set "_simple_view_merging"=TRUE;

-- start prepare window-- these steps will NOT update any data yet.

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 installed:

SQL> exec DBMS_DST.BEGIN_PREPARE(13)BEGIN DBMS_DST.BEGIN_PREPARE(13); END;

*ERROR at line 1:ORA-30094: failed to find the time zone data file for version 13 in$ORACLE_HOME/oracore/zoneinfoORA-06512: at "SYS.DBMS_DST", line 57ORA-06512: at "SYS.DBMS_DST", line 1258ORA-06512: at line 1

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:

SQL> exec DBMS_DST.BEGIN_PREPARE(4);BEGIN DBMS_DST.BEGIN_PREPARE(4); END;

*ERROR at line 1:ORA-56921: invalid time zone versionORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "SYS.DBMS_DST", line 1252ORA-06512: at line 1

FIX: you cannot "downgrade" DST, there is no need to do this. The new DST version needs to be higher than the current DST_PRIMARY_TT_VERSION

-- check for prepare status

SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) valueFROM DATABASE_PROPERTIESWHERE PROPERTY_NAME LIKE 'DST_%'ORDER BY PROPERTY_NAME;

-- output should be-- PROPERTY_NAME VALUE-- ------------------------------ -------------------------------- DST_PRIMARY_TT_VERSION <the old DST version number>-- 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 onBEGINDBMS_DST.FIND_AFFECTED_TABLES(affected_tables => 'sys.dst$affected_tables',log_errors => TRUE,log_errors_table => 'sys.dst$error_table');END;/If this failes withERROR at line 1:ORA-01882: timezone region not foundORA-06512: at "SYS.DBMS_DST", line 284ORA-06512: at "SYS.DBMS_DST", line 1511ORA-06512: at line 2the first of all run the Fix1882.sql script found in Note 414590.1 using the server home sqlplus and then retry DBMS_DST.FIND_AFFECTED_TABLES -- check what tables have affected data in TSTZ columns.-- if dst$affected_tables has no rows then there is no actual data to update by DBMS_DST-- if dst$affected_tables has rows it simply means those rows need -- to be updated by DBM_DST during the DST upgrade (= point 4)-- because they contain timezones that are affected by the DST upgrade

SELECT * FROM sys.dst$affected_tables;

-- If dst$affected_tables has rows then you can see in dst$error_table-- if there are any rows with a "problem" and what kind of problem there are in those rows-- note that if there are rows in dst$affected_tables -- this does not mean there need to be rows in dst$error_table

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 an explanation of the reported data please see-- "Error Handling when Upgrading Time Zone File and Timestamp with Time Zone Data"-- For the "error_on_overlap_time" and "error_on_nonexisting_time" you do not HAVE 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');

1882 errors will be resolved by DBMS_DST if the cause is the issue explained in Note 414590.1 those should be corrected during the actual update of the dst version. It is however possible some other reasons may cause 1882 but in that case DBMS_DST.FIND_AFFECTED_TABLES would have also errored out with ora-1882.

-- end prepare window, the rows above will stay in those tables.

EXEC DBMS_DST.END_PREPARE;

-- check if this is ended


-- output should be-- PROPERTY_NAME VALUE-- ---------------------------- -------------------------------- DST_PRIMARY_TT_VERSION <the old DST version number>-- DST_SECONDARY_TT_VERSION 0-- DST_UPGRADE_STATE NONE

If sys.dst$error_table has no "error_on_overlap_time" or "error_on_nonexisting_time" rows or there are rows in sys.dst$error_table but you are fine by the fact they might change one hour then go to point 4)

to do the actual update.

If sys.dst$error_table has "error_on_overlap_time" or "error_on_nonexisting_time" rows and you want to check things afterwards then make a note of what rows are affected and manually update the data (if needed) after doing the actual update in step 4)

4) Do the actual RDBMS DST version update of the database using DBMS_DST in your 11.2.0.x database:

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_nonexisting_time => FALSE);For RAC the database should be in single instance mode (cluster_database = false) , as required by the "startup UPGRADE", if not then an ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE will be seen.-- the actual commands are listed in BOLD-- 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 want to update to.

conn / as sysdbashutdown immediate;startup upgrade;set serveroutput on

-- check if previous prepare window is ended


-- output should be-- PROPERTY_NAME VALUE-- ---------------------------- -------------------------------- DST_PRIMARY_TT_VERSION <the old DST version number>-- DST_SECONDARY_TT_VERSION 0-- DST_UPGRADE_STATE NONE

-- 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 bin 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;

-- this alter session might speed up DBMS_DST on some db's-- see Bug 10209691 / Bug 12658443

alter session set "_with_subquery"=materialize;

-- to avoid the issue in note 1407273.1

alter session set "_simple_view_merging"=TRUE;

-- 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 loadingof a secondary time zone data file is in an active stateORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "SYS.DBMS_DST", line 1054ORA-06512: at line 1

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/zoneinfoORA-06512: at "SYS.DBMS_DST", line 57ORA-06512: at "SYS.DBMS_DST", line 1076ORA-06512: at line 1

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 windoORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "SYS.DBMS_DST", line 1091ORA-06512: at line 1

FIX: start the database in UPGRADE mode -- check if this select give no rows, if it does something went wrong


-- check if this select gives


-- gives this output:-- PROPERTY_NAME VALUE-- --------------------------- -------------------------------- DST_PRIMARY_TT_VERSION <the new DST version number>-- DST_SECONDARY_TT_VERSION <the old DST version number>-- DST_UPGRADE_STATE UPGRADE

-- Optionally you can check what user tables still need to be updated using DBMS_DST.UPGRADE_DATABASE-- BEGIN_UPGRADE upgrades system tables that contain TSTZ data and marks user tables (containing TSTZ data) with the UPGRADE_IN_PROGRESS property. -- even if this select gives no rows you still need to do to the rest of the steps-- it simply gives an indication of how many user objects need to processed in the later steps-- some oracle provided users may be listed here, that is normal

SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS='YES';

-- now restart the database-- NOTE: Oracle support has seen SR's where some customers stop here, the upgrade is NOT finished yet - please DO follow the next steps !!!!!

shutdown immediatestartup

-- at this point the database can actually be used note however that the-- upgrade_database will take exclusive locks on the tables when they are actually upgraded-- so it might provoke issues.

alter session set "_with_subquery"=materialize;alter session set "_simple_view_merging"=TRUE;

-- now upgrade the tables who need action

set serveroutput onVAR numfail numberBEGINDBMS_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 like:

-- Table list: SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S-- Number of failures: 0-- ....-- Table list: SYSMAN.MGMT_PROV_ASSIGNMENT-- Number of failures: 0-- Table list: SYSMAN.MGMT_CONFIG_ACTIVITIES-- Number of failures: 0-- Failures:0

-- this select should , if no errors where given also give "no rows", if it does something went wrong


-- if there where no failures then end the upgrade.

VAR fail numberBEGINDBMS_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 failedORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "SYS.DBMS_DST", line 1169ORA-06512: at line 2

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:-- PROPERTY_NAME VALUE-- ---------------------------- -------------------------------- DST_PRIMARY_TT_VERSION <the new DST version number>-- DST_SECONDARY_TT_VERSION 0-- DST_UPGRADE_STATE NONE

SELECT * FROM v$timezone_file;

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

Note: make sure to exit this session, do not use it for timezone related selects , it still uses the old timezone version

Your database DST version is now updated to <the new DST version number>.

Optionally you can also do this :

-- if registry$database exists then update this static table also with the new DST version-- the TZ_VERSION in registry$database is populated by Oracle's Database Pre-Upgrade Utility-- wich is the utlu112i%.sql script-- this table is ONLY used during upgrade and contains the DST version from before the upgrade-- this update is mainly to avoid confusion when people notice registry$database has a lower DST version-- listed than seen in DATABASE_PROPERTIES or v$timezone_fileconn / as sysdbaSELECT VERSION FROM v$timezone_file;select TZ_VERSION from registry$database;--if they differ after an upgrade then updating registry$database can be done byconn / as sysdbaupdate registry$database set TZ_VERSION = (select version FROM v$timezone_file);commit;

If needed, start over from step 3a) for the next database in the same ORACLE_HOME.

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

An Oracle 11gR2 Clients will use the highest timezlrg_XX.dat found in the ORACLE_HOME.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 example. The DST version only comes to play when actually using DST related information in SQL.For an Oracle client simply apply the RDBMS DST patch using Opatch or manually.

6) How long will DBMS_DST take?

This mainly depends on the amount of TSTZ rows you have in your database - this will affect the time needed for:

EXEC DBMS_DST.FIND_AFFECTED_TABLES during the check fase EXEC DBMS_DST.BEGIN_UPGRADE (the amount of data in sys

objects like DBMS_SCHEDULER tables ) EXEC DBMS_DST.UPGRADE_DATABASE (the amount of data in user

tables)

This select will give a count(*) of all tables that have a TSTZ column (= processed by dbms_dst) and have actual data (= count (*) is >0 ):

conn / as sysdbaset serveroutput onDECLAREcountstar NUMBER;stmt VARCHAR2(1000);BEGINFOR rec in( select distinct c.owner, c.table_namefrom dba_tab_cols c, dba_objects owhere c.data_type like '%WITH TIME ZONE'and c.owner=o.ownerand c.table_name = o.object_nameand o.object_type = 'TABLE'order by c.owner, c.table_name)LOOPstmt := 'select count(*) from "' || rec.owner || '"."' || rec.table_name || '"' ;execute immediate stmt into countstar;IF countstar > 0 THENDBMS_OUTPUT.PUT_LINE(rec.owner||'.'|| rec.table_name|| ' - count * is : ' || countstar );END IF;END LOOP;END;/

* For most databases the biggest amount of data that is affected by DST updates will be in DBMS_SCHEDULER tables. If DBMS_SCHEDULER is not used for own jobs or is used but there is no need to keep the history then it might be an idea to purge the DBMS_SCHDULER logging information using

Conn / as sysdbaexec dbms_scheduler.purge_log;

Sometimes this purge does not work: Note 749440.1 Dbms_scheduler.Purge Not Removing Entries from dba_scheduler_job_run_details

* Other often seen tables are SYS.WRI$_OPTSTAT_HISTGRM_HISTORY and SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY, this can be used to remove / reduce the nr of rows if needed (if there are many rows in those tables ):

Conn / as sysdba-- check current nr of rows in HISTHEAD / HISTGRMselect count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;-- check the current retention of stats

-- the default value is 31select systimestamp - dbms_stats.get_stats_history_availability from dual;-- now disable stats retentionexec dbms_stats.alter_stats_history_retention(0);-- remove all statsexec DBMS_STATS.PURGE_STATS(systimestamp);-- check result of purgeselect count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;-- AFTER the DST update you can set the retention back to the original valueexec dbms_stats.alter_stats_history_retention(31);

7) Known Issues with DBMS_DST in 11.2.0.x:

Issues who are NOT detected during the check fase:

* an ORA-54017: UPDATE operation disallowed on virtual columns error is seen during DBMS_DST.UPGRADE_DATABASE :

ERROR at line 1: ORA-54017: UPDATE operation disallowed on virtual columns ORA-6512: at "SYS.DBMS_DST", line 1094 ORA-6512: at line 2

If this select returns rows you might encounter this:

select c.owner, c.table_name, c.column_name from dba_tab_cols c, dba_objects o where c.data_type like '%WITH TIME ZONE' and c.virtual_column ='YES' and c.owner=o.owner and c.table_name = o.object_name and o.object_type = 'TABLE';

This is Bug 13436809: ORA-54017 UPDATE OPERATION DISALLOWED ON VIRTUAL COLUMNS ERROR RUNNING DBMS_DST Fixed in 11.2.0.4 and 12cIf the column name is system generated ( SYS_NC00003$ for example) then this means function based indexes are on the reported table who can be dropped , see Note < span="" 1="" 1369179="" gt="">DST upgrade fails with ORA-54017 when running DBMS_DST.UPGRADE_DATABASE stepIf the column name is not system generated then ask a backport of the bugfix

Issues who ARE detected during the check fase:

* 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 column specification.

This is fixed in 11.2.0.2To 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(column_name) != column_name);

Workaround (for 11.2.0.1): rename the column(s) to a non-Case insensitive name and then rename them back after wards using ALTER TABLE ... RENAME COLUMN .. TO ..; and/or the table name using ALTER TABLE ... RENAME TO ...;

* if DBMS_DST.BEGIN_PREPARE fails with ORA-00907: missing right parenthesis

BEGIN DBMS_DST.BEGIN_PREPARE((<the new DST version number>)); END;

ERROR at line 1:ORA-56922: Starting a prepare window failedORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "SYS.DBMS_DST", line 1366ORA-06512: at line 1

then it is possible that the shared pool is unable to allocate additional storage during the execution of the DBMS_DST.BEGIN_PREPARE package. Flush the shared pool or bounced the database to free up the SGA.

* if DBMS_DST.FIND_AFFECTED_TABLES fails with ORA-00907: missing right parenthesis

SQL> set serveroutput onSQL> BEGIN2 DBMS_DST.FIND_AFFECTED_TABLES3 (affected_tables => 'sys.dst$affected_tables',4 log_errors => TRUE,5 log_errors_table => 'sys.dst$error_table');6 END;7 /BEGIN*ERROR at line 1:ORA-00907: missing right parenthesisORA-06512: at "SYS.DBMS_DST", line 284ORA-06512: at "SYS.DBMS_DST", line 1511ORA-06512: at line 2

Then this issue may be caused by1) DBMS_DST not handling TIMESTAMP WITH TIME ZONE data type as part of an object subtype, this is mostly seen with Oracle Data Miner objects installed by SQL Developer ( ODMRSYS objects).This select will give all objects that may cause this error:

select OWNER,TABLE_NAME, QUALIFIED_COL_NAME from ALL_TSTZ_TAB_COLS where instr(QUALIFIED_COL_NAME,'TREAT',1,1) > 0;

if above select gives rows then this is Bug 13833939 - ora-0907 when preparing for dst upgrade., Fixed in 11.2.0.4 and 12c

2) unused timestamp with time zone columns This select will give all objects that may cause this error:

select OWNER,TABLE_NAME, QUALIFIED_COL_NAME from DBA_TSTZ_TAB_COLS where QUALIFIED_COL_NAME like ('SYS_C0%');

if there are (=above select give rows) drop the unused columns using "alter table owner.table drop unused columns;" <Bug 14732853> - DBMS_DST DOES NOT HANDLE UNUSED TIMESTAMP WITH TIME ZONE COLUMNS , not fixed yet

* if DBMS_DST.FIND_AFFECTED_TABLES fails with ORA-00904: "T"."SYS_C00001_-random number here-": invalid identifier

DBMS_DST.FIND_AFFECTED_TABLES(affected_tables => 'sys.dst$affected_tables',log_errors => TRUE,log_errors_table => 'sys.dst$error_table');END;/

BEGIN*ERROR at line 1:ORA-00904: "T"."SYS_C00001_10101608:45:57$": invalid identifier ORA-06512: at "SYS.DBMS_DST", line 284 ORA-06512: at "SYS.DBMS_DST", line 1515 ORA-06512: at line 2

Then this issue may be caused by unused timestamp with time zone columns

This select will give all objects that may cause this error:

select OWNER,TABLE_NAME, QUALIFIED_COL_NAME from DBA_TSTZ_TAB_COLS where QUALIFIED_COL_NAME like ('SYS_C0%');

if there are (=above select give rows) drop the unused columns using "alter table owner.table drop unused columns;"<Bug 14732853> - DBMS_DST DOES NOT HANDLE UNUSED TIMESTAMP WITH TIME ZONE COLUMNS , not fixed yet

* if DBMS_DST.BEGIN_PREPARE fail with ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.

Bug 10138792 ORA-2014 ON SEGMENT ADVISOR SELECT STMT WHEN _SIMPLE_VIEW_MERGING=FALSE, closed as not a bug. (the statements in this note use the workaround)note 1407273.1 DST Upgrade using DBMS_DST.BEGIN_PREPARE fail with ORA-2014

Non blocking / non-error provoking issues:

* DBMS_DST is very slow on some databases

Bug 10209691 SLOW PERFORMANCE ON ALL_TSTZ_TAB_COLSNot fixed yet (the statements in this note use the workaround)Workaround: use "alter session set "_with_subquery"=materialize;" in the session running DBMS_DST

* if the database is still in DST upgrade mode then select from timestamp with timezone columns will give the data without the second fractions

so if


-- gives this output:-- PROPERTY_NAME VALUE-- --------------------------- -------------------------------- DST_PRIMARY_TT_VERSION <the new DST version number>-- DST_SECONDARY_TT_VERSION <the old DST version number>-- DST_UPGRADE_STATE UPGRADE

then you will see missing fractions

SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT ='DD/MM/YYYY HH24:MI:SS.FF TZR TZD';

Session altered.

SQL> select * from scott.test1;

COL1----------COL2---------------------------------------------------------------------------120/01/2012 20:30:34. +05:30

228/06/2007 00:00:00. AUSTRALIA/MELBOURNE EST

320/01/2012 20:30:34. +05:30

solution: run DBMS_DST.UPGRADE_DATABASE and then DBMS_DST.END_UPGRADE(:fail);

Not a bug:

* EXEC DBMS_DST.BEGIN_PREPARE (or any other DBMS_DST call) fails with 'PLS-00201: identifier 'DBMS_DST.-insert name here-' must be declared':

SQL> EXEC DBMS_DST.BEGIN_PREPARE(14);BEGIN DBMS_DST.BEGIN_PREPARE(14); END;

*ERROR at line 1:ORA-06550: line 1, column 7:PLS-00201: identifier 'DBMS_DST.BEGIN_PREPARE' must be declaredORA-06550: line 1, column 7:PL/SQL: Statement ignored

You try to run DBMS_DST in a Oracle database that is NOT Version 11.2.0.1 or higher. This is typically seen when upgrading and the wrong impression is that DBMS_DST need to be run before the upgrade, this is not true, DBMS_DST is used AFTER the Oracle RDBMS version upgrade is done .

* Not an DBMS_DST issue but good to know when using AQ Propagation note 1286513.1 PROPAGATION ERRORS ORA-30757 ON 11GR2 AFTER PATCHSET UPGRADEThis is fixed in 11.2.0.3 and higher

8) Can the DST version be updated in 11.2.0.x without downtime? Or in a "rolling" fashion on RAC?

No.

* For the apply of the DST patch itself using Opatch or manually ( if needed) -> no downtime needed.* For the check fase of DBMS_DST ( point 3 in this note) -> no downtime needed* For the first part of the actual upgrade ( point 4 in this note after the "shutdown immediate/startup upgrade") -> downtime needed and the RAC database should be in single instance mode (cluster_database = false) , as required by the "startup UPGRADE", if not then an ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE will be seen.* For the second part of the actual upgrade ( steps in point 4 in this note after the "shutdown immediate/startup") -> no downtime is needed, note however that the DBMS_DST.UPGRADE_DATABASE will take exclusive locks on the non-SYS tables when they are actually upgraded, so this might provoke issues (dealocks have been observed) and we suggest to NOT start any applications who use the tables processed until the complete DST update is done.

References

NOTE:1358166.1 - Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3 PatchsetNOTE:815679.1 - Actions For DST Updates When Upgrading To 11.2.0.1 Base ReleaseNOTE:1201253.1 - Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 PatchsetNOTE:412160.1 - Updated DST transitions and new Time Zones in Oracle Time Zone File patchesBUG:10209691 - SLOW PERFORMANCE ON ALL_TSTZ_TAB_COLSNOTE:414590.1 - Time Zone IDs for 7 Time Zones Changed in Time Zone Files Version 3 and Higher, Possible ORA-1882 After UpgradeBUG:13833939 - ORA-0907 WHEN PREPARING FOR DST UPGRADE.NOTE:1407273.1 - DST Upgrade using DBMS_DST.BEGIN_PREPARE fail with ORA-2014NOTE:1255474.1 - Different Time Zone Version In Registry$Database And V$Timezone_file

NOTE:749440.1 - DBMS_SCHEDULER.PURGE Not Removing Entries from DBA_SCHEDULER_JOB_RUN_DETAILS

updating the rdbms dst version in 11g release 2 (11.2.0.1 and up) using dbms_dst [id 977512.1]

Documents