问题描述：

    在使用数据泵导入数据时报如下错误。数据是从oracle 19c，Version 19.9.0.0.0版本中导出的。要导入到19c Version 19.22.0.0.0版本中。

Import: Release 19.0.0.0.0 - Production on Thu Jul 11 17:30:00 2024
Version 19.22.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
ORA-39006: internal error
ORA-39065: unexpected master process exception in DISPATCH
ORA-56935: existing datapump jobs are using a different version of time zone data file
ORA-06512: at "SYS.DBMS_DST", line 1849
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.DBMS_DST", line 1812
ORA-06512: at "SYS.KUPM$MCP", line 20452
ORA-06512: at "SYS.KUPM$MCP", line 13059
ORA-06512: at "SYS.KUPM$MCP", line 12435
ORA-06512: at "SYS.KUPM$MCP", line 15079
ORA-06512: at "SYS.KUPM$MCP", line 10315
ORA-39097: Data Pump job encountered unexpected error -56935

问题原因：

     出现的问题有可能是之前一次的datapump操作没有正常退出，比如强制退出的。没有清除DST_UPGRADE_STATE. 当执行多个job 同时导入时也有可能导致此问题。 这是BUG 11836540. 据MOS文档中说明，在12.2 中已经被修复。但是我在19C 中仍遇到。

处理方案：

    在mos上查询到两个资料 (Doc ID 2471020.1)和  (Doc ID 1307959.1)，资料中介绍可以使用如下的方法进行处理。

connect / as sysdba
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     11
DST_SECONDARY_TT_VERSION   3
DST_UPGRADE_STATE          DATAPUMP(1)

从上面查询的结果可以看到， DST_UPGRADE_STATE 的 value 值是DATAPUMP(1), 正常应该是NONE. 下面进行修复:

connect / as sysdba
ALTER SESSION SET EVENTS '30090 TRACE NAME CONTEXT FOREVER, LEVEL 32';
exec dbms_dst.unload_secondary;

再次查看 DST_UPGRADE_STATE的值:

connect / as sysdba
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     11
DST_SECONDARY_TT_VERSION   3
DST_UPGRADE_STATE              NONE

修改完成后，再次导入执行成功。

下面是mos上两篇相关的文章。为了没有mos的兄弟查询。

第一篇

ORA-39065 And ORA-56935 Errors When Running Impdp On 12c R2 Database (Doc ID 2471020.1)

In this Document

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.2.0.1 and later
Information in this document applies to any platform.

SYMPTOMS

Below errors are seen while running import process in 12.2.0.1 database:

CHANGES

None

CAUSE

The errors are caused by the fact that a previous DataPump import job exited ungracefully, without cleaning up DST_UPGRADE_STATE due to secondary timezone table.
The errors could be also introduced after multiple import jobs were running and changed the data in the secondary timezone table.

This can be checked with the following query:

Above query shows the row having DATAPUMP(<x>) value where <x> is a number equal or greater than 1 for DST_UPGRADE_STATE property.

This problem is addressed in below 2 bugs:

•  Unpublished Bug 11836540 - ABORTED DATA PUMP DID NOT CLEAN UP DST_UPGRADE_STATE

Even if the fix for the Bug 11836540 was included in 12.2 as mentioned in Doc ID 1307959.1 the problem still persist.

• Unpublished Bug 27529356 - DATA PUMP IMPORT FAILS WITH ORA-56935 ERROR   

SOLUTION

1. Apply interim  patch 27529356, if available for your platform and Oracle version.

To check for conflicting patches, please use the MOS Patch Planner Tool
Please refer to
Note 1317012.1 - How To Use MOS Patch Planner To Check And Request The Conflict Patches?

If no patch exists for your version, please contact Oracle Support for a backport request.

    - Or -

2. Use workaround:

Then re-check the new value for DST_UPGRADE_STATE property. This should return "NONE". If the value for DATAPUMP was > 1 (for example DATAPUMP(2) or DATAPUMP(3) ) then it might be  needed to call dbms_dst.unload_secondary several times until the return value will be "NONE".
After that, restart the import.
 

REFERENCES

NOTE:1307959.1  - DataPump Import Fails With Errors ORA-39097 ORA-39065 ORA-56935 / ORA-56938

第二篇

DataPump Import Fails With Errors ORA-39097 ORA-39065 ORA-56935 / ORA-56938 (Doc ID 1307959.1)

In this Document

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.2 to 12.1.0.2 [Release 11.2 to 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Information in this document applies to any platform.

SYMPTOMS

DataPump import fails with the following errors:

 - or -

CHANGES

CAUSE

The errors are caused by the fact that a previous DataPump import job exited ungracefully, without cleaning up DST_UPGRADE_STATE due to secondary timezone table.
The errors could be also introduced after multiple import jobs were running and changed the data in the secondary timezone table.

This can be checked with the following query:

Above query shows the row having DATAPUMP(<x>) value where <x> is a number equal or greater than 1 for DST_UPGRADE_STATE property.

This problem is addressed in unpublished
Bug 11836540 - ABORTED DATA PUMP DID NOT CLEAN UP DST_UPGRADE_STATE

The bug is fixed in 12.2.

SOLUTION

To solve the issue, use any of below alternatives:

• Upgrade to 12.2 when available
  
  - OR -
  
  
• Apply interim  Patch 11836540, if available for your platform and Oracle version.
  
  To check for conflicting patches, please use the MOS Patch Planner Tool
  Please refer to
  Note 1317012.1 - How To Use MOS Patch Planner To Check And Request The Conflict Patches?
  
  If no patch exists for your version, please contact Oracle Support for a backport request.
  
  - OR -
  
  
• Use next workaround:
  connect / as sysdba
  ALTER SESSION SET EVENTS '30090 TRACE NAME CONTEXT FOREVER, LEVEL 32';
  exec dbms_dst.unload_secondary;
  
  Then re-check the new value for DST_UPGRADE_STATE property. This should return "NONE". If the value for DATAPUMP was > 1 (for example DATAPUMP(2) or DATAPUMP(3) ) then it might be needed to call dbms_dst.unload_secondary several times until the return value will be "NONE".
  After that, restart the import.