Oracle Data Pump is one of the most powerful tools used by DBAs for migrating schemas, performing backups, and moving data between databases. However, during an import operation, you may encounter a frustrating error related to time zone file versions.

One common issue is:

ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version X into a target database with TSTZ version Y.

In this guide, we’ll walk through a real-world scenario, understand why this error occurs, and explain how to resolve it safely by upgrading the target database timezone version.

---

Understanding the ORA-39405 Error

During an Oracle Data Pump import (impdp), the database checks compatibility between the source database timezone version and the target database timezone version.

If the source database has a higher timezone version, the import will fail.

Example error:

ORA-39002: invalid operation
ORA-39405: Oracle Data Pump does not support importing from a source database 
with TSTZ version 44 into a target database with TSTZ version 32.

This means:

Database	Timezone Version
Source Database	44
Target Database	32

Since 32 < 44, Oracle prevents the import to avoid inconsistencies in TIMESTAMP WITH TIME ZONE data.

---

Real Scenario: Import Failure During Schema Migration

In this case, a DBA attempted to import a schema using Oracle Data Pump.

Import Command Used

impdp system/******* \
REMAP_SCHEMA=APPUSRUAT:TESTUSER \
directory=DATA_DIR \
dumpfile=APPUSRUAT_2026.dmp \
logfile=APPUSRUAT_2026_imp.log \

But the import failed immediately with:

ORA-39002: invalid operation
ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version 44 into a target database with TSTZ version 32.

---

Step 1 — Check Current Timezone Version

To confirm the timezone version of the target database, connect as SYSDBA and run:

SELECT * FROM v$timezone_file;

Example output:

FILENAME        VERSION
-----------------------
timezlrg_32.dat   32

This confirms the target database timezone version is 32, which is older than the source database version 44.

Therefore, the target database must be upgraded to timezone version 44.

---

Step 2 — Shutdown the Database

First, shut down the database cleanly.

SHUT IMMEDIATE;

Output:

Database closed.
Database dismounted.
ORACLE instance shut down.

---

Step 3 — Start Database in Upgrade Mode

Start the database in upgrade mode.

STARTUP UPGRADE;

Upgrade mode allows internal system changes like timezone upgrades.

---

Step 4 — Begin Timezone Upgrade Window

Enable server output and start the timezone upgrade process.

SET SERVEROUTPUT ON

Run the following PL/SQL block:

DECLARE
  l_tz_version PLS_INTEGER;
BEGIN
  l_tz_version := DBMS_DST.get_latest_timezone_version;  DBMS_OUTPUT.put_line('l_tz_version=' || l_tz_version);
  DBMS_DST.begin_upgrade(l_tz_version);
END;
/

Example output:

l_tz_version=44
An upgrade window has been successfully started.

This step prepares the database for the timezone upgrade.

---

Step 5 — Restart the Database

Shutdown and restart the database normally.

SHUT IMMEDIATE;

Then start it again:

STARTUP;

---

Step 6 — Upgrade the Database Timezone Version

Now execute the actual timezone upgrade.

SET SERVEROUTPUT ON
DECLARE
  l_failures PLS_INTEGER;
BEGIN
  DBMS_DST.upgrade_database(l_failures);
  DBMS_OUTPUT.put_line('DBMS_DST.upgrade_database : l_failures=' || l_failures);  DBMS_DST.end_upgrade(l_failures);
  DBMS_OUTPUT.put_line('DBMS_DST.end_upgrade : l_failures=' || l_failures);
END;
/

Example output:

Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0Table list: "MDSYS"."SDO_DIAG_MESSAGES_TABLE"
Number of failures: 0DBMS_DST.upgrade_database : l_failures=0
An upgrade window has been successfully ended.

This confirms that the timezone upgrade completed successfully without failures.

---

Step 7 — Verify the New Timezone Version

Now confirm the upgrade.

Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0Table list: "MDSYS"."SDO_DIAG_MESSAGES_TABLE"
Number of failures: 0DBMS_DST.upgrade_database : l_failures=0
An upgrade window has been successfully ended.

Expected output:

FILENAME          VERSION
-------------------------
timezlrg_44.dat     44

The database timezone version is now 44, matching the source database.

---

Step 8 — Run Data Pump Import Again

Now rerun the import command.

impdp system/****** \
REMAP_SCHEMA=APPUSRUAT:TESTUSER \
directory=DATA_DIR \
dumpfile=APPUSRUAT_2026.dmp \
logfile=APPUSRUAT_2026imp.log \

Import output:

Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01"
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE

This time, the import proceeds successfully.

---

Why Oracle Enforces Timezone Compatibility

Oracle enforces timezone compatibility because timestamp data depends on timezone definitions.

If the target database uses an older timezone file:

• Daylight Saving Time changes may differ
• Historical timezone rules may not match
• Timestamp conversions may become inconsistent

Therefore, Oracle blocks the import to prevent data corruption or incorrect timestamp interpretation.

---

Best Practices to Avoid This Issue

DBAs can avoid this error by following these best practices:

1️⃣ Check timezone versions before migration

SELECT * FROM v$timezone_file;

Run on both source and target databases.

---

2️⃣ Upgrade timezone versions before migrations

Ensure the target database timezone version is equal or higher than the source.

---

3️⃣ Maintain consistent patch levels

Keep databases updated with the latest RU (Release Updates).

---

4️⃣ Test migrations in staging environments

Always test Data Pump exports and imports before production migrations.

---

Conclusion

The ORA-39405 timezone mismatch error is a common challenge when performing Oracle Data Pump migrations between databases with different timezone versions.

In this article, we covered:

• Why the error occurs
• How to identify timezone version mismatches
• How to upgrade the database timezone using DBMS_DST
• How to successfully rerun the Data Pump import

By ensuring timezone compatibility before migration, DBAs can avoid import failures and ensure a smooth and reliable data migration process.