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

1]
In this Document Purpose Details 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 DSTv11 2b) 11.2.0.2 and 11.2.0.3: When updating to a RDBMS DST version higher than DSTv14 3) 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 ORA00904: 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 upgrade 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 Note 1358166.1 Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3

0.2 or 11.x.2. etc) home before doing the version upgrade to 11gR2.2.sql ) scripts in order to apply a RDBMS DST patch.0.) after the Oracle version upgrade to 11gR2 will be simply the same as the DST version that was used in the older RDBMS version.2. Oracle 11.2.0.2.2.2.2.x . Oracle cannot say to what DST version you need to use.0.0.x . There are however a few situations where some extra steps are needed before doing the version upgrade.2.. 10.0.    Oracle 11.2.1.0. This also implies that:    There is no need to apply "DST patches" to the OLD version (11.0.x.1.x.0.3 side before the version upgrade .1 has by default all RDBMS DST updates from DSTv1 to DSTv11 included in the software installation.0.etc) version on the 11.x.0.1 and the older Oracle version (11.0. this simply depends on if you are using DST information or not in SQL.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.x .3 has by default all RDBMS DST updates from DSTv1 to DSTv14 included in the software installation. 10. If you want to upgrade to 11.0.2 / 11. so please do check above notes before upgrading to 11gR2.0.2 has by default all RDBMS DST updates from DSTv1 to DSTv14 included in the software installation.. See Note 412160.x.2 and is applicable to 11. 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.0.2.2.3 and the older Oracle version (11. 11.x .1 section " E) I'm on DSTv <insert current version of your db> . Oracle 11.2. etc) is using a RDBMS DST version higher than DSTv14 you need to install the SAME DST version as the old (11.0.2.0. 10. If you want to upgrade to 11.1. .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. .1 and later.x.1 side before the version upgrade. For Oracle versions 11. After the Oracle version upgrade to 11. 10.sql (utltzuv2.0.2 and higher.0.sql. it's no longer necessary to use utltzuvX.1.x DBMS_DST can then be used to do an upgrade of the RDBMS DST version of the 11gR2 database. 10.1.etc) version on the 11.0..0. 11.x.2. utltzuv13.2.2. These files are found in $ORACLE_HOME/oracore/zoneinfo and have a prefix indicating the DST version.0.

0. .2.0.2 versions.2.3 using the same ORACLE_HOME. 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.dat. this is normal and intended.For example timezlrg_4. for 11.2.0. 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.2.0.dat found in the ORACLE_HOME.dat in 11.dat is the DSTv4 "large" file.3/etc database * a DSTv4 11. After a DST patch is installed in an 11.0. aldo there is in real life little need to do so.1/11.dat and timezone.0.2. On windows the ORA_TZFILE needs to be set in the registry.2 versions).2. This allows several databases who are using the same $ORACLE_HOME to each use a different RDBMS DST version.2.dat and timezone.2.dat is the DSTv11 "large" file.0.dat and timezone.2 DSTv14 and for 11.2 or 11.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.0.x databases to at least to the highest RDBMS DST version included by default in the Oracle 11gR2 version.1 DSTv11 .2 and up there should be NO timezlrg. This is for 11.2.2.0. Note that when creating a new 11.x $ORACLE_HOME there are steps who need to be done to change an existing database to use this newer DST version.0.3 database and a DSTv14 11. if needed . update each database. This also implies that if one $ORACLE_HOME is used by several databases you need check and . Do NOT make any symbolic links for timezlrg.3 DSTv14.0.2.2. something that was not possible in pre-11.3 any new database created by the DBCA using the "includes datafiles" templates in step 2 of the DBCA will be using DSTv14.dat in $ORACLE_HOME/oracore/zoneinfo/ (unix) or %ORACLE_HOME%\oracore\zoneinfo\ (windows) By default the "Create database" statement uses the highest timezlrg_XX. not a real "create database".2 and up there are no timezlrg. We recommend in general to update 11. In 11.0. In 11.dat or copy any of the files in \oracore\zoneinfo\ and rename them to timezlrg.2.0. So it is perfectly possible (and supported) to have for example * a DSTv4 (or any other RDBMS DST version) 11.1 onwards the used RDBMS DST version is a database level configuration. From version 11.dat and timezone. timezlrg_11.

2.0. an Oracle 11.2 software installation.2. DSTv1 to DSTv14 RDBMS DST files are included in the Oracle 11.1 RDBMS DST patches for DSTv1 to DSTv11.2 DSTv14 and for 11.2.2.2. so there are no Oracle 11. an Oracle 11.2.2. 2) When do I need to apply RDBMS DST patches to the 11.0. For more information please see the docset.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. This is for 11. 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).0. for 11.0.1 RDBMS to DSTv11 then simply go to step 3a) and use 11 as <the new DST version number> in the statements.1 : When updating to a RDBMS DST version higher than DSTv11 .1 DSTv11 .3 RDBMS DST patches for DSTv1 to DSTv14. so there are no Oracle 11.x database.There are however situations where it makes perfect sence to use an older RDBMS DST version for an 11.2.0.0.3 DSTv14.2 database in the 11. DSTv1 to DSTv11 RDBMS DST files are included in the Oracle 11. DSTv1 to DSTv14 RDBMS DST files are included in the Oracle 11.3 RDBMS to DSTv14 then simply go to step 3a) and use 14 as <the new DST version number> in the statements.0.0.x ORACLE_HOME before using DBMS_DST (= before going to step 3) in this note)? When you want to update an 11.0.2. 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.0.2 RDBMS to DSTv14 then simply go to step 3a) and use 14 as <the new DST version number> in the statements.2. So if you want to update:    an Oracle 11.2. Note that it is NOT possible to have different OJVM DST patches/version in one $ORACLE_HOME.0.0.0.0. If you want to update the DST version of an EXISITING (= no update of the Oracle version) 11. so there are no Oracle 11.1 software installation.2.2 RDBMS DST patches for DSTv1 to DSTv14.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".0.2.3 software installation.2.2.

2.0. for example if you want to go from DSTv11 to DSTv16 then there is no need to install RDBMS DSTv12. there is no need to shutdown the database to apply the RDBMS DST patch in 11.1 database to the latest DST patch then it's not needed to install all DST patches "in between". Locate the latest RDBMS DST patch (this is currently DSTv19 patch 15897859 ).0.2.2.x database. SUBSTR(property_value.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. 13. 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.0.1 (this is DSTv16 patch 12320006).0.x database: If needed.0.2 and 11.0. All the RDBMS DST update notes are available in NOTE:412160. 17 and 18 patches also (but it can be done if you want) only the DSTv19 RDBMS patch is needed.If you want to update an existing 11. The actual DST update itself is done in step 4) of this note. 1.2 or 11.3: When updating to a RDBMS DST version higher than DSTv14 If you want to update an existing 11. 16. Locate the latest RDBMS DST patch for 11.2.2. All the RDBMS DST update notes are available in NOTE:412160. for example if you want to go from DSTv14 to DSTv19 then there is no need to install RDBMS DSTv15.3 database to the latest DST patch then it's not needed to install all DST patches "in between".2. Continue in step 3) 2b) 11.2.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.2. 3a) check current RDBMS DST version and "DST UPGRADE STATUS" in your 11. 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME.2. make sure the required RDBMS DST patch(es) is/are applied (= step 2 in this note was followed).0. conn / as sysdba SELECT PROPERTY_NAME.0. 14 and 15 patches also (but it can be done if you want) only the DSTv16 RDBMS patch is needed.

check if an other DBA is doing a upgrade.0. if not then go to step 4). if it is set then remove this from your 11. 3b) Check UPFRONT using DBMS_DST if there is affected data that cannot be resolved automatically in your 11.2.THIS NEEDS TO BE "0" !!! DST_UPGRADE_STATE NONE <<<<-----. * This is a DATABASE operation. PREPARE or DATAPUMP status: * if DST_UPGRADE_STATE is "DATAPUMP" then simply wait until the datapump load is done or check Note 336014.x home settings and restart the database and listener. simply replace it with the actual number ( 11. even if they use the same ORACLE_HOME. so it needs to be done for each database you want to update. solving DST_UPGRADE_STATE in UPGRADE. Note: * The next steps use <the new DST version number> in the statements.DST_PRIMARY_TT_VERSION should match the value found when selecting SELECT version FROM v$timezone_file.BEGIN_UPGRADE steps (!) in step 4 and do the steps after that.-----------------------------DST_PRIMARY_TT_VERSION <the old DST version number> DST_SECONDARY_TT_VERSION 0 <<<<-----. Note: Also check that ORA_TZFILE is NOT set in the environment of your 11.THIS NEEDS TO BE "NONE" !!! -.2. . DST_SECONDARY_TT_VERSION is 0 and DST_UPGRADE_STATE is NONE go to 3b) If DST_UPGRADE_STATE is UPGRADE.0.1 How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? * if DST_UPGRADE_STATE is "PREPARE" then execute an EXEC DBMS_DST. 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.dat . If DST_PRIMARY_TT_VERSION is <the old DST version number>. .-. 15 etc) of the RDBMS DST version you want to update to.x database.dat or $ORACLE_HOME/oracore/zoneinfo/timezone.2.0. 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.END_PREPARE.x database to $ORACLE_HOME/oracore/zoneinfo/timezlrg. skip the truncate and EXEC DBMS_DST.check that the output gives -----PROPERTY_NAME VALUE -----------------------------.

see Bug 10209691 / Bug 12658443 alter session set "_with_subquery"=materialize. * The steps in this point 3b) will NOT update any data and NOT update the DST version .BEGIN_PREPARE(13). line 57 ORA-06512: at "SYS.please purge the bin now. purge dba_recyclebin. -. -. END. conn / as sysdba -. live database.DBMS_DST". ----- 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. exec DBMS_DST. -.start prepare window -.2 DST patch for the requested DST version is not installed: SQL> exec DBMS_DST.this alter session might speed up DBMS_DST on some db's -.DBMS_DST".If there are objects containing TSTZ data in recycle bin.1 alter session set "_simple_view_merging"=TRUE. line 1258 ORA-06512: at line 1 . it's a pure "check" faze using DBMS_DST. -.these steps will NOT update any data yet.BEGIN_PREPARE(13) BEGIN DBMS_DST.BEGIN_PREPARE(<the new DST version number>) Sample error if the 11.to avoid the issue in note 1407273.* The steps in point 3b) can be done on a working. 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. Of course it might that there is data added between this session and the actual upgrade of the RDBMS DST version that is affected. 15 etc) of the RDBMS DST version you want to update to. * ERROR at line 1: ORA-30094: failed to find the time zone data file for version 13 in $ORACLE_HOME/oracore/zoneinfo ORA-06512: at "SYS. 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.

log_errors_table => 'sys. log_errors => TRUE.DST$TRIGGER_TABLE.BEGIN_PREPARE(4).truncate logging tables if they exist.dst$affected_tables. -.dst$error_table'). BEGIN DBMS_DST.1 Sample error if the requested new DST version is the current or a lower than the current timezone version: SQL> exec DBMS_DST.DBMS_SYS_ERROR". line 1252 ORA-06512: at line 1 FIX: you cannot "downgrade" DST. there is no need to do this.dst$error_table.BEGIN_PREPARE(4). 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME.check for prepare status SELECT PROPERTY_NAME.dst$affected_tables'. END.-----------------------------DST_PRIMARY_TT_VERSION <the old DST version number> DST_SECONDARY_TT_VERSION <the new DST version number> DST_UPGRADE_STATE PREPARE -. TRUNCATE TABLE sys. TRUNCATE TABLE SYS. END. / If this failes with ERROR at line 1: ORA-01882: timezone region not found .FIX: install the 11. * ERROR at line 1: ORA-56921: invalid time zone version ORA-06512: at "SYS. See note 412160.DBMS_DST".2 patch for the DST version you want to use. 1. SUBSTR(property_value. TRUNCATE TABLE sys. line 79 ORA-06512: at "SYS. The new DST version needs to be higher than the current DST_PRIMARY_TT_VERSION -.log affected data set serveroutput on BEGIN DBMS_DST.FIND_AFFECTED_TABLES (affected_tables => 'sys. ------output should be PROPERTY_NAME VALUE -----------------------------.

1 those should be corrected during the actual update of the dst version. -.for an explanation of the reported data please see -. -.'1883'). -.check for all other possible problems SELECT * FROM sys.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 -. but it is advised -."Error Handling when Upgrading Time Zone File and Timestamp with Time Zone Data" -.this does not mean there need to be rows in dst$error_table SELECT * FROM sys.1 using the server home sqlplus and then retry DBMS_DST.to at least to check the results AFTER the update. It is however possible some other reasons .note that if there are rows in dst$affected_tables -. 1882 errors will be resolved by DBMS_DST if the cause is the issue explained in Note 414590. -.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. -.all "error_on_nonexisting_time" rows SELECT * FROM sys.sql script found in Note 414590.dst$affected_tables.DBMS_DST".ORA-06512: at "SYS.if there are any rows with a "problem" and what kind of problem there are in those rows -. line 1511 ORA-06512: at line 2 the first of all run the Fix1882.because they contain timezones that are affected by the DST upgrade SELECT * FROM sys.error_on_overlap_time is error number ORA-1883 -.to be updated by DBM_DST during the DST upgrade (= point 4) -.FIND_AFFECTED_TABLES -.DBMS_DST".if dst$affected_tables has rows it simply means those rows need -.dst$error_table where ERROR_NUMBER= '1883'. -.dst$error_table.error_on_nonexisting_time is error number ORA-1878 -.all "error_on_overlap_time" rows SELECT * FROM sys. line 284 ORA-06512: at "SYS.dst$error_table where ERROR_NUMBER not in ('1878'.If dst$affected_tables has rows then you can see in dst$error_table -.dst$error_table where ERROR_NUMBER= '1878'.

so using for DBMS_DST.UPGRADE_DATABASE error_on_overlap_time => FALSE and error_on_nonexisting_time => FALSE). the rows above will stay in those tables. If sys.-----------------------------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. SUBSTR(property_value.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.2.x database: Assuming all non-existing time and overlap times in previous step are solved or logged.end prepare window.check if this is ended SELECT PROPERTY_NAME. EXEC DBMS_DST. if not then an ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE will be seen.FIND_AFFECTED_TABLES would have also errored out with ora-1882. ------output should be PROPERTY_NAME VALUE ---------------------------. 1. 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME.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. ----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. .0.may cause 1882 but in that case DBMS_DST. as required by the "startup UPGRADE".END_PREPARE. -. For RAC the database should be in single instance mode (cluster_database = false) . 15 etc) of the RDBMS DST version you want to update to. startup upgrade. conn / as sysdba shutdown immediate. -.

.dst$error_table.If DST_UPGRADE_STATE is "PREPARE" then you did not ended the prepare window in step 3) -. -. 1.will be seen Sample error if a previous (prepare) window was not ended: SQL> EXEC DBMS_DST.see Bug 10209691 / Bug 12658443 alter session set "_with_subquery"=materialize." -. -. -.start upgrade window EXEC DBMS_DST. -.BEGIN_UPGRADE(<the new DST version number>).-----------------------------DST_PRIMARY_TT_VERSION <the old DST version number> DST_SECONDARY_TT_VERSION 0 DST_UPGRADE_STATE NONE -. -.BEGIN_UPGRADE(11). ------output should be PROPERTY_NAME VALUE ---------------------------.check if previous prepare window is ended SELECT PROPERTY_NAME. TRUNCATE TABLE sys. purge dba_recyclebin. SUBSTR(property_value.DST$TRIGGER_TABLE.to avoid the issue in note 1407273. 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME. -.If there are objects containing TSTZ data in recycle bin. TRUNCATE TABLE sys.dst$affected_tables.please purge the bin now.the message -.Otherwise dbms_dst.set serveroutput on -.clean used tables TRUNCATE TABLE SYS."An upgrade window has been successfully started.begin_upgrade will report "ORA-38301: Can not perform DDL/DML over objects in Recycle Bin".1 alter session set "_simple_view_merging"=TRUE. -.this alter session might speed up DBMS_DST on some db's -.

* ERROR at line 1: ORA-30094: failed to find the time zone data file for version 13 in $ORACLE_HOME/oracore/zoneinfo ORA-06512: at "SYS." step in point 3) Sample error if the requested DST version / patch is not installed: SQL> EXEC DBMS_DST. line 1054 ORA-06512: at line 1 FIX: You NEED to end the "PREPARE" window in the previous step BEFORE doing the UPGRADE.1 Sample error if the database is not in upgrade mode: SQL> EXEC DBMS_DST. line 79 ORA-06512: at "SYS. line 79 ORA-06512: at "SYS. line 57 ORA-06512: at "SYS.BEGIN_UPGRADE(13).BEGIN DBMS_DST. See note 412160.DBMS_DST". END.BEGIN_UPGRADE(11).DBMS_DST".check if this select give no rows. * 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 ORA-06512: at "SYS.DBMS_DST". -.2 patch for the DST version you want to use. END. BEGIN DBMS_DST.BEGIN_UPGRADE(11). line 1076 ORA-06512: at line 1 FIX: Install the 11. END. Or in other words.DBMS_DST". BEGIN DBMS_DST. you did not do the "EXEC DBMS_DST. if it does something went wrong SELECT * FROM sys.BEGIN_UPGRADE(13). line 1091 ORA-06512: at line 1 FIX: start the database in UPGRADE mode -.BEGIN_UPGRADE(11).check if this select gives .DBMS_SYS_ERROR".dst$error_table.END_PREPARE. * ERROR at line 1: ORA-56926: database must be in UPGRADE mode in order to start an upgrade windo ORA-06512: at "SYS.DBMS_SYS_ERROR".

UPGRADE_DATABASE -. parallel => TRUE. the upgrade is NOT finished yet .please DO follow the next steps !!!!! shutdown immediate startup -.Optionally you can check what user tables still need to be updated using DBMS_DST.some oracle provided users may be listed here. 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME.-----------------------------DST_PRIMARY_TT_VERSION <the new DST version number> DST_SECONDARY_TT_VERSION <the old DST version number> DST_UPGRADE_STATE UPGRADE -. log_errors => TRUE. UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS='YES'.UPGRADE_DATABASE(:numfail.now upgrade the tables who need action set serveroutput on VAR numfail number BEGIN DBMS_DST.at this point the database can actually be used note however that the -.so it might provoke issues. -.it simply gives an indication of how many user objects need to processed in the later steps -.even if this select gives no rows you still need to do to the rest of the steps -. SUBSTR(property_value. -.upgrade_database will take exclusive locks on the tables when they are actually upgraded -.BEGIN_UPGRADE upgrades system tables that contain TSTZ data and marks user tables (containing TSTZ data) with the UPGRADE_IN_PROGRESS property. that is normal SELECT OWNER.now restart the database -. ------gives this output: PROPERTY_NAME VALUE --------------------------. -. alter session set "_with_subquery"=materialize. alter session set "_simple_view_merging"=TRUE. .SELECT PROPERTY_NAME.NOTE: Oracle support has seen SR's where some customers stop here. 1. TABLE_NAME.

if it does something went wrong SELECT * FROM sys. / Sample error if DBMS_DST.ouput of this will be a list of tables like: --------Table list: SYSMAN. line 1169 ORA-06512: at line 2 FIX: start database normally and run DBMS_DST.END_UPGRADE(:fail). line 79 ORA-06512: at "SYS.last checks SELECT PROPERTY_NAME.DST$TRIGGER_TABLE'. END. END. -.log_errors_table => 'SYS.An upgrade window has been successfully ended. SUBSTR(property_value. 1. / -.MGMT_CONFIG_ACTIVITIES Number of failures: 0 Failures:0 -.this select should ..output that will be seen: -.DBMS_DST". error_on_overlap_time => FALSE.PUT_LINE('Failures:'|| :fail).DST$ERROR_TABLE'.DBMS_SYS_ERROR". VAR fail number BEGIN DBMS_DST. DBMS_OUTPUT. 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' .PUT_LINE('Failures:'|| :numfail). error_on_nonexisting_time => FALSE). Table list: SYSMAN. -.Failures:0 -.UPGRADE_DATABASE was not issued: ERROR at line 1: ORA-56929: Ending an upgrade window failed ORA-06512: at "SYS.if there where no failures then end the upgrade.AQ$_MGMT_NOTIFY_QTABLE_S Number of failures: 0 ..dst$error_table..MGMT_PROV_ASSIGNMENT Number of failures: 0 Table list: SYSMAN. DBMS_OUTPUT. log_triggers_table => 'SYS. if no errors where given also give "no rows".UPGRADE_DATABASE -.

commit.wich is the utlu112i%. it still uses the old timezone version Your database DST version is now updated to <the new DST version number>. ------needed output: PROPERTY_NAME VALUE ---------------------------. . select TZ_VERSION from registry$database.the TZ_VERSION in registry$database is populated by Oracle's Database Pre-Upgrade Utility -.-----------------------------DST_PRIMARY_TT_VERSION <the new DST version number> DST_SECONDARY_TT_VERSION 0 DST_UPGRADE_STATE NONE SELECT * FROM v$timezone_file.dat <new version> Note: make sure to exit this session.ORDER BY PROPERTY_NAME. Optionally you can also do this : -.sql script -. ----needed output: FILENAME VERSION -----------------. start over from step 3a) for the next database in the same ORACLE_HOME.this table is ONLY used during upgrade and contains the DST version from before the upgrade -. If needed.if registry$database exists then update this static table also with the new DST version -.this update is mainly to avoid confusion when people notice registry$database has a lower DST version -. --if they differ after an upgrade then updating registry$database can be done by conn / as sysdba update registry$database set TZ_VERSION = (select version FROM v$timezone_file).---------timezlrg_<new version>.listed than seen in DATABASE_PROPERTIES or v$timezone_file conn / as sysdba SELECT VERSION FROM v$timezone_file. do not use it for timezone related selects . 5) Applying a new RDBMS DST version to 11gR2 clients.

FIND_AFFECTED_TABLES during the check fase EXEC DBMS_DST.table_name = o.owner || '". aldo there is in real life little need to do so.owner and c.table_name || '"' ."' || rec.table_name) LOOP stmt := 'select count(*) from "' || rec.owner.dat found in the ORACLE_HOME. A DSTv13 11.2. 6) How long will DBMS_DST take? This mainly depends on the amount of TSTZ rows you have in your database . END LOOP. stmt VARCHAR2(1000).BEGIN_UPGRADE (the amount of data in sys objects like DBMS_SCHEDULER tables ) EXEC DBMS_DST.object_type = 'TABLE' order by c. c.object_name and o.0.1 client can perfectly connect to an non-DSTv13 server for example.owner.data_type like '%WITH TIME ZONE' and c. BEGIN FOR rec in ( select distinct c. c.table_name|| ' .table_name from dba_tab_cols c.An Oracle 11gR2 Clients will use the highest timezlrg_XX. For an Oracle client simply apply the RDBMS DST patch using Opatch or manually.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 sysdba set serveroutput on DECLARE countstar NUMBER.owner=o.count * is : ' || countstar ). dba_objects o where c. The DST version only comes to play when actually using DST related information in SQL.owner||'. END IF. IF countstar > 0 THEN DBMS_OUTPUT.'|| rec.PUT_LINE(rec. END. This can be overwritten by setting explicit the ORA_TZFILE variable (which is by default not set).this will affect the time needed for:    EXEC DBMS_DST. execute immediate stmt into countstar. / .

2. -.WRI$_OPTSTAT_HISTGRM_HISTORY and SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY.1 Dbms_scheduler.WRI$_OPTSTAT_HISTGRM_HISTORY. 7) Known Issues with DBMS_DST in 11.the default value is 31 select systimestamp .alter_stats_history_retention(31).UPGRADE_DATABASE : ERROR at line 1: ORA-54017: UPDATE operation disallowed on virtual columns ORA-6512: at "SYS.check current nr of rows in HISTHEAD / HISTGRM select count(*) from SYS.dbms_stats.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. 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 sysdba exec dbms_scheduler.purge_log.check the current retention of stats -.WRI$_OPTSTAT_HISTGRM_HISTORY.check result of purge select count(*) from SYS.* For most databases the biggest amount of data that is affected by DST updates will be in DBMS_SCHEDULER tables.alter_stats_history_retention(0).DBMS_DST". -.get_stats_history_availability from dual. line 1094 ORA-6512: at line 2 If this select returns rows you might encounter this: . -. this can be used to remove / reduce the nr of rows if needed (if there are many rows in those tables ): Conn / as sysdba -. select count(*) from SYS. -.remove all stats exec DBMS_STATS. select count(*) from SYS. -.AFTER the DST update you can set the retention back to the original value exec dbms_stats. Sometimes this purge does not work: Note 749440.0.now disable stats retention exec dbms_stats.WRI$_OPTSTAT_HISTHEAD_HISTORY.Purge Not Removing Entries from dba_scheduler_job_run_details * Other often seen tables are SYS.PURGE_STATS(systimestamp).WRI$_OPTSTAT_HISTHEAD_HISTORY.

column..column. and/or the table name using ALTER TABLE .table. 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).0. This is Bug 13436809: ORA-54017 UPDATE OPERATION DISALLOWED ON VIRTUAL COLUMNS ERROR RUNNING DBMS_DST Fixed in 11.2.BEGIN_PREPARE((<the new DST version number>)). c.select c.table_name.. or column specification.2.column_name from dba_tab_cols c..BEGIN_PREPARE package.4 and 12c If 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 . END. RENAME TO . line 79 ORA-06512: at "SYS.DBMS_SYS_ERROR". dba_objects o where c. Flush the shared pool or bounced the database to free up the SGA. RENAME COLUMN .. Workaround (for 11.UPGRADE_DATABASE step If 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 ORA00904: invalid identifier or ORA-01747: invalid user.owner and c.DBMS_DST"..table_name = o.object_type = 'TABLE'.0.virtual_column ='YES' and c...object_name and o.2. see Note < span="" 1="" 1369179="" gt="">DST upgrade fails with ORA-54017 when running DBMS_DST. line 1366 ORA-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. c. table_name. TO . table. ERROR at line 1: ORA-56922: Starting a prepare window failed ORA-06512: at "SYS.owner=o.2 To see if you have possible affected objects : select owner.0.owner. * if DBMS_DST..data_type like '%WITH TIME ZONE' and c.1): rename the column(s) to a non-Case insensitive name and then rename them back after wards using ALTER TABLE . .. This is fixed in 11.BEGIN_PREPARE fails with ORA-00907: missing right parenthesis BEGIN DBMS_DST..

if above select gives rows then this is Bug 13833939 . not fixed yet * if DBMS_DST.dst$affected_tables'. .4 and 12c 2) unused timestamp with time zone columns This select will give all objects that may cause this error: select OWNER." <Bug 14732853> . QUALIFIED_COL_NAME from DBA_TSTZ_TAB_COLS where QUALIFIED_COL_NAME like ('SYS_C0%').dst$error_table'). line 1511 ORA-06512: at line 2 Then this issue may be caused by 1) DBMS_DST not handling TIMESTAMP WITH TIME ZONE data type as part of an object subtype."SYS_C00001_-random number here-": invalid identifier DBMS_DST. QUALIFIED_COL_NAME from ALL_TSTZ_TAB_COLS where instr(QUALIFIED_COL_NAME.FIND_AFFECTED_TABLES 3 (affected_tables => 'sys.* if DBMS_DST. if there are (=above select give rows) drop the unused columns using "alter table owner.'TREAT'.2.DBMS_DST". This select will give all objects that may cause this error: select OWNER..ora-0907 when preparing for dst upgrade.DBMS_DST".table drop unused columns. line 284 ORA-06512: at "SYS. 4 log_errors => TRUE.FIND_AFFECTED_TABLES (affected_tables => 'sys. this is mostly seen with Oracle Data Miner objects installed by SQL Developer ( ODMRSYS objects).TABLE_NAME. 5 log_errors_table => 'sys. 7 / BEGIN * ERROR at line 1: ORA-00907: missing right parenthesis ORA-06512: at "SYS.TABLE_NAME.0.1.FIND_AFFECTED_TABLES fails with ORA-00904: "T".FIND_AFFECTED_TABLES fails with ORA-00907: missing right parenthesis SQL> set serveroutput on SQL> BEGIN 2 DBMS_DST. Fixed in 11.1) > 0.DBMS_DST DOES NOT HANDLE UNUSED TIMESTAMP WITH TIME ZONE COLUMNS . 6 END.dst$affected_tables'.

1 DST Upgrade using DBMS_DST. (the statements in this note use the workaround) note 1407273. log_errors_table => 'sys." <Bug 14732853> .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_COLS Not fixed yet (the statements in this note use the workaround) Workaround: use "alter session set "_with_subquery"=materialize. line 284 ORA-06512: at "SYS."SYS_C00001_10101608:45:57$": invalid identifier ORA-06512: at "SYS. etc. GROUP BY. closed as not a bug. Bug 10138792 ORA-2014 ON SEGMENT ADVISOR SELECT STMT WHEN _SIMPLE_VIEW_MERGING=FALSE. 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. QUALIFIED_COL_NAME from DBA_TSTZ_TAB_COLS where QUALIFIED_COL_NAME like ('SYS_C0%').DBMS_DST".TABLE_NAME. if there are (=above select give rows) drop the unused columns using "alter table owner. / BEGIN * ERROR at line 1: ORA-00904: "T"." 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 .dst$error_table').DBMS_DST". END. not fixed yet * if DBMS_DST.DBMS_DST DOES NOT HANDLE UNUSED TIMESTAMP WITH TIME ZONE COLUMNS .BEGIN_PREPARE fail with ORA-02014: cannot select FOR UPDATE from view with DISTINCT.table drop unused columns.log_errors => TRUE.

30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME. +05:30 solution: run DBMS_DST.END_UPGRADE(:fail).SELECT PROPERTY_NAME. 1.FF TZR TZD'.BEGIN_PREPARE (or any other DBMS_DST call) fails with 'PLS-00201: identifier 'DBMS_DST. Not a bug: * EXEC DBMS_DST.test1. Session altered.BEGIN_PREPARE(14). +05:30 2 28/06/2007 00:00:00.-insert name here-' must be declared': SQL> EXEC DBMS_DST. ------gives this output: PROPERTY_NAME VALUE --------------------------.UPGRADE_DATABASE and then DBMS_DST. END.BEGIN_PREPARE(14). SUBSTR(property_value. BEGIN DBMS_DST. AUSTRALIA/MELBOURNE EST 3 20/01/2012 20:30:34.-----------------------------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. * . COL1 ---------COL2 -------------------------------------------------------------------------1 20/01/2012 20:30:34. SQL> select * from scott.

2. column 7: PLS-00201: identifier 'DBMS_DST. this is not true.ERROR at line 1: ORA-06550: line 1. * For the apply of the DST patch itself using Opatch or manually ( if needed) -> no downtime needed.3 and higher 8) Can the DST version be updated in 11. column 7: PL/SQL: Statement ignored You try to run DBMS_DST in a Oracle database that is NOT Version 11.Actions For DST Updates When Upgrading To Or Applying The 11. * Not an DBMS_DST issue but good to know when using AQ Propagation note 1286513.1 PROPAGATION ERRORS ORA-30757 ON 11GR2 AFTER PATCHSET UPGRADE This is fixed in 11. References NOTE:1358166. * For the second part of the actual upgrade ( steps in point 4 in this note after the "shutdown immediate/startup") -> no downtime is needed.2. This is typically seen when upgrading and the wrong impression is that DBMS_DST need to be run before the upgrade. as required by the "startup UPGRADE". * 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) .BEGIN_PREPARE' must be declared ORA-06550: line 1.0.0.2. if not then an ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE will be seen.3 Patchset .0.1 . 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. note however that the DBMS_DST.UPGRADE_DATABASE will take exclusive locks on the non-SYS tables when they are actually upgraded.0.x without downtime? Or in a "rolling" fashion on RAC? No.2.1 or higher. DBMS_DST is used AFTER the Oracle RDBMS version upgrade is done .

0.Updated DST transitions and new Time Zones in Oracle Time Zone File patches BUG:10209691 . Possible ORA-1882 After Upgrade BUG:13833939 .1 .1 Base Release NOTE:1201253.2.Time Zone IDs for 7 Time Zones Changed in Time Zone Files Version 3 and Higher.1 .NOTE:815679.2 Patchset NOTE:412160.BEGIN_PREPARE fail with ORA-2014 NOTE:1255474.Different Time Zone Version In Registry$Database And V$Timezone_file NOTE:749440.Actions For DST Updates When Upgrading To Or Applying The 11.1 .SLOW PERFORMANCE ON ALL_TSTZ_TAB_COLS NOTE:414590.PURGE Not Removing Entries from DBA_SCHEDULER_JOB_RUN_DETAILS .1 .2.DBMS_SCHEDULER.Actions For DST Updates When Upgrading To 11.1 .DST Upgrade using DBMS_DST.1 .0.ORA-0907 WHEN PREPARING FOR DST UPGRADE.1 . NOTE:1407273.