Oracle 21c and Time Zone Patches: The Unexpected Adventure to DSTv42

When Oracle Data Pump Says “Not So Fast…”

I recently ran into one of those situations that makes every DBA smile, sigh, and laugh at the same time. After building a fresh Oracle 21c environment, I assumed I was ready to import a database export created from another Oracle environment. Everything looked normal—until Data Pump reminded me that assumptions are dangerous.

			
ORA-39002: invalid operation
ORA-39405: Oracle Data Pump does not support importing from a source database
with TSTZ version 36 into a target database with TSTZ version 35.
ORA-39154: Objects from foreign schemas have been removed from import

The culprit? Time Zone File versions.

The source database was running a newer Time Zone version, while my Oracle 21c target database was still using DST Version 35.

Wait… Oracle 21c Still Ships with DSTv35?

This is where things get interesting.

Oracle Database 21c ships with DST Version 35 by default. What surprised me was discovering that newer Daylight Saving Time (DST) patches are regularly bundled with Oracle 19c Release Updates, but not necessarily with Oracle 21c installations.

As a DBA, it feels a bit ironic:

You’re running a newer database version, but you still need to manually patch time zone files before importing data from a database that is effectively “living in the future.”

For most organizations this may never become an issue because 21c adoption is relatively limited compared to 19c. The good news is that Oracle provides updated DST patches through My Oracle Support, and the process is straightforward once you know what’s happening.

Verifying the Existing Time Zone Version

Before doing anything, I checked the database DST version.

SELECT * FROM V$TIMEZONE_FILE;

Result:

			
timezlrg_35.dat
VERSION = 35

That confirmed the target database was still running DSTv35.

Downloading the Latest Time Zone Patch

I downloaded patch 35220732, which contains the newer DST files for Oracle 21c.

Before applying any patch, I always verify conflicts:

Enabling Online Time Zone Upgrade

Oracle 21c introduces an online upgrade capability controlled by:

SHOW PARAMETER TIMEZONE_VERSION_UPGRADE_ONLINE;

Mine was disabled:

FALSE

So I enabled it:

ALTER SYSTEM SET TIMEZONE_VERSION_UPGRADE_ONLINE = TRUE;

Applying the Patch

			
oracle@dbadeeds-01 Ora-Installers]$ cd 35220732
[oracle@dbadeeds-01 35220732]$ . oraenv
ORACLE_SID = [cdb1] ? orcl
The Oracle base has been changed from /data1/oracle/ to /data1/oracle
[oracle@dbadeeds-01 35220732]$ cd $ORACLE_HOME
[oracle@dbadeeds-01 db]$ cd -
/data1/Ora-Installers/35220732
[oracle@dbadeeds-01 35220732]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.26
Copyright (c) 2026, Oracle Corporation.  All rights reserved.
PREREQ session 
Oracle Home       : /data1/oracle/product/21/db
Central Inventory : /data1/oracle
   from           : /data1/oracle/product/21/db/oraInst.loc
OPatch version    : 12.2.0.1.26
OUI version       : 12.2.0.9.0
Log file location : /data1/oracle/product/21/db/cfgtoollogs/opatch/opatch2026-06-18_08-39-16AM_1.log
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.
[oracle@dbadeeds-01 35220732]$ $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.26
Copyright (c) 2026, Oracle Corporation.  All rights reserved.
Oracle Home       : /data1/oracle/product/21/db
Central Inventory : /data1/oracle
   from           : /data1/oracle/product/21/db/oraInst.loc
OPatch version    : 12.2.0.1.26
OUI version       : 12.2.0.9.0
Log file location : /data1/oracle/product/21/db/cfgtoollogs/opatch/opatch2026-06-18_08-41-55AM_1.log
Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   35220732
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Backing up files...
Applying interim patch '35220732' to OH '/data1/oracle/product/21/db'
Patching component oracle.oracore.rsf, 21.0.0.0.0...
Patch 35220732 successfully applied.
Log file location: /data1/oracle/product/21/db/cfgtoollogs/opatch/opatch2026-06-18_08-41-55AM_1.log
OPatch succeeded.

		

Starting the DST Upgrade

After patching, I initiated the upgrade to DST Version 42.

EXEC DBMS_DST.BEGIN_UPGRADE(42);

Then verified the database properties:

			
SELECT VALUE$, CON_ID
FROM CONTAINERS(SYS.PROPS$)
WHERE NAME='DST_PRIMARY_TT_VERSION';

The database correctly recognized DSTv42 as the target version.

Running Oracle’s Upgrade Scripts

Oracle provides two scripts that handle the heavy lifting:

Step 1 – Validation

			
@?/rdbms/admin/utltz_upg_check.sql
SQL> start ?/rdbms/admin/utltz_upg_check.sql
Session altered.
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 21.0.0.0 .
INFO: This database is a Multitenant database.
INFO: Current container is CDB$ROOT .
INFO: Updating the RDBMS DST version of the CDB / CDB$ROOT database
INFO: will NOT update the RDBMS DST version of PDB databases in this CDB.
WARNING: There are 1 open PDBs .
WARNING: They will be closed when running utltz_upg_apply.sql .
INFO: Database RDBMS DST version is DSTv35 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
A prepare window has been successfully started.
INFO: Newest RDBMS DST version detected is DSTv42 .
INFO: Next step is checking all TSTZ data.
INFO: It might take a while before any further output is seen ...
A prepare window has been successfully ended.
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run utltz_upg_apply.sql to do the actual RDBMS DST update.
INFO: Note that the utltz_upg_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.

		

Step 2 – Apply Upgrade

			
@?/rdbms/admin/utltz_upg_apply.sql
SQL> start ?/rdbms/admin/utltz_upg_apply.sql
Session altered.
INFO: If an ERROR occurs, the script will EXIT SQL*Plus.
INFO: The database RDBMS DST version will be updated to DSTv42 .
INFO: This database is a Multitenant database.
INFO: Current container is CDB$ROOT .
INFO: Updating the RDBMS DST version of the CDB / CDB$ROOT database
INFO: will NOT update the RDBMS DST version of PDB databases in this CDB.
WARNING: There are 1 open PDBs .
WARNING: They will be closed when CDB$ROOT is restarted
WARNING: This script will restart the database 2 times
WARNING: WITHOUT asking ANY confirmation.
WARNING: Hit control-c NOW if this is not intended.
INFO: Restarting the database in UPGRADE mode to start the DST upgrade.
Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.
Total System Global Area 1.0033E+10 bytes
Fixed Size                  9696192 bytes
Variable Size            1912602624 bytes
Database Buffers         8086618112 bytes
Redo Buffers               23855104 bytes
Database mounted.
Database opened.
INFO: Starting the RDBMS DST upgrade.
INFO: Upgrading all SYS owned TSTZ data.
INFO: It might take time before any further output is seen ...
An upgrade window has been successfully started.
INFO: Restarting the database in NORMAL mode to upgrade non-SYS TSTZ data.
Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.
Total System Global Area 1.0033E+10 bytes
Fixed Size                  9696192 bytes
Variable Size            1912602624 bytes
Database Buffers         8086618112 bytes
Redo Buffers               23855104 bytes
Database mounted.
Database opened.
INFO: Upgrading all non-SYS TSTZ data.
INFO: It might take time before any further output is seen ...
INFO: Do NOT start any application yet that uses TSTZ data!
INFO: Next is a list of all upgraded tables:
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_L"
Number of failures: 0
Table list: "DBSNMP"."MGMT_DB_FEATURE_LOG"
Number of failures: 0
Table list: "WMSYS"."WM$METADATA_MAP_TBL"
Number of failures: 0
Table list: "WMSYS"."AQ$_WM$EVENT_QUEUE_TABLE_S"
Number of failures: 0
Table list: "WMSYS"."AQ$_WM$EVENT_QUEUE_TABLE_L"
Number of failures: 0
Table list: "WMSYS"."WM$WORKSPACES_TABLE$"
Number of failures: 0
Table list: "WMSYS"."WM$MP_PARENT_WORKSPACES_TABLE$"
Number of failures: 0
Table list: "WMSYS"."WM$WORKSPACE_SAVEPOINTS_TABLE$"
Number of failures: 0
Table list: "DVSYS"."AUDIT_TRAIL$"
Number of failures: 0
Table list: "DVSYS"."SIMULATION_LOG$"
Number of failures: 0
Table list: "MDSYS"."SDO_DIAG_MESSAGES_TABLE"
Number of failures: 0
INFO: Total failures during update of TSTZ data: 0 .
An upgrade window has been successfully ended.
INFO: Your new Server RDBMS DST version is DSTv42 .
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this SQL*Plus session.
INFO: Do not use it for timezone related selects.

		

Oracle clearly warns:

			
This script will restart the database 2 times
WITHOUT asking ANY confirmation.

Always good to know before running it in production.

Successful Upgrade to DSTv42

After the process completed:

			
SELECT property_name, property_value
FROM database_properties
WHERE property_name LIKE 'DST_%';

Output:

			
DST_PRIMARY_TT_VERSION = 42
DST_UPGRADE_STATE      = NONE

And finally:

SELECT * FROM V$TIMEZONE_FILE;

Result:

			
timezlrg_42.dat
VERSION = 42

Success.

Even the PDB reflected the new version:

			
ALTER SESSION SET CONTAINER=P_ORCL_21;
SELECT * FROM V$TIMEZONE_FILE;

			
timezlrg_42.dat
VERSION = 42

Lessons Learned

Oracle 21c still ships with DSTv35 by default.
Data Pump imports can fail when source and target DST versions don’t match.
Don’t assume a newer database release includes the latest time zone files.
Always verify V$TIMEZONE_FILE before migrations or imports.
Oracle’s DST upgrade process is straightforward once the patch is installed.

DBADEEDS