Upgrading timezone manually in 12c
May 20, 2017 5 Comments
After manual upgrade from 12.1.0.2 to 12.2.0.1 oracle pre/post upgrade scripts required to upgrade timezone manually.
Our database was using timezone datafile version 18 and the target 12.2.0.1.0 database ships with timezone datafile version 26.
Updating timezone is somehow complicated process.
I will provide you with the steps that we have used:
The whole steps are described on metalink note : Doc ID 1509653.1
- Check the current version
SQL> select TZ_VERSION from registry$database;
TZ_VERSION
———-
18
- Check aslo
SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME; PROPERTY_NAME VALUE --------------------------- ---------- DST_PRIMARY_TT_VERSION 18 DST_SECONDARY_TT_VERSION 0 DST_UPGRADE_STATE NONE
If DST_PRIMARY_TT_VERSION is <the old DST version number>, DST_SECONDARY_TT_VERSION is 0 and DST_UPGRADE_STATE is NONE then continue, otherwise you need to see Note 1509653.1
- Purge recyclebin
sqlplus / as sysdba 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(26);
— truncate logging tables if they exist.
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE; TRUNCATE TABLE sys.dst$affected_tables; TRUNCATE TABLE sys.dst$error_table; SQL> select * from sys.dst$affected_tables; no rows selected SQL> select * from sys.dst$error_table; no rows selected
–If there is no error then end the prepare
EXEC DBMS_DST.END_PREPARE;
5. If error_table is empty we can run the actual timezone upgrade
sqlplus / as sysdba shutdown immediate; startup upgrade; purge dba_recyclebin; TRUNCATE TABLE SYS.DST$TRIGGER_TABLE; TRUNCATE TABLE sys.dst$affected_tables; TRUNCATE TABLE sys.dst$error_table; EXEC DBMS_APPLICATION_INFO.SET_CLIENT_INFO('upg_tzv') alter session set "_with_subquery"=materialize; alter session set "_simple_view_merging"=TRUE; exec DBMS_DST.BEGIN_UPGRADE(26); SQL> SELECT * FROM sys.dst$error_table; no rows selected SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME; PROPERTY_NAME VALUE ------------------------- ------------------------------------ DST_PRIMARY_TT_VERSION 26 DST_SECONDARY_TT_VERSION 18 DST_UPGRADE_STATE UPGRADE
— some oracle provided users may be listed here, that is normal
SQL> SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS='YES'; shutdown immediate startup alter session set "_with_subquery"=materialize; alter session set "_simple_view_merging"=TRUE;
— now upgrade the tables who need action
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; /
— this select should return now rows
SELECT * FROM sys.dst$error_table;
— 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; /
— Check
SQL> SELECT * FROM v$timezone_file; FILENAME VERSION CON_ID -------------------- ---------- ---------- timezlrg_26.dat 26 0 SQL> SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME; PROPERTY_NAME VALUE ----------------- ---------- DST_PRIMARY_TT_VERSION 26 DST_SECONDARY_TT_VERSION 18 DST_UPGRADE_STATE NONE
–Check the following:
SELECT VERSION FROM v$timezone_file; VERSION ------------- 26
select TZ_VERSION from registry$database; TZ_VERSION --------- 18
–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); commit;
Thanks a lot for the very helpful post.
Please Update the post in paragraph 5.) with exec DBMS_DST.BEGIN_UPGRADE(26);
instead of exec DBMS_DST.BEGIN_PREPARE(26);
Thanks a lot
Thank you very much for your comment. I have corrected that , thanks a lot!
This unleashes havoc on VPD INSERT and UPDATE policies on tables with timestamp and TZ columns. We had ORA-1733’s on every table with this column type until this process was applied. Thanks!
Thank you Mariami for the very helpful walkthrough. The timezone upgrade worked flawlessly for our database.
Thank you so much, the steps were straight forward. I was able to upgrade quickly.