Home  >  Article  >  Database  >  expdp遭遇ORA-39006、ORA-39065、ORA-01403、ORA-39097错误

expdp遭遇ORA-39006、ORA-39065、ORA-01403、ORA-39097错误

WBOY
WBOYOriginal
2016-06-07 17:18:451727browse

今天使用expdp数据泵导出数据时报错了。[oracle@srccat dumpdp]$ expdp srcb/srcb directory=dumpdir dumpfile=srcb.20120221.dm

今天使用expdp数据泵导出数据时报错了。

[Oracle@srccat dumpdp]$ expdp srcb/srcb directory=dumpdir dumpfile=srcb.20120221.dmp

Export: Release 10.2.0.4.0 - Production on Tuesday, 21 February, 2012 11:11:20

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39006: internal error
ORA-39065: unexpected master process exception in DISPATCH
ORA-01403: no data found

ORA-39097: Data Pump job encountered unexpected error 100

虽然不像网上其他人碰到的还出现ORA-00600的错误,但是照着网上的做法,重新生成一些 DATAPUMP API用到的视图问题就解决了:

可以参考一下Metalink上的文章:

EXPDP FAILS WITH ORA-600 [UNABLE TO LOAD XDB LIBRARY] [ID 736049.1]

  修改时间 23-JUN-2010     类型 PROBLEM     状态 PUBLISHED  

In this Document
  
  
  
  

Applies to: Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.5.0 - Release: 10.2 to 10.2

SymptomsThis article is written specifically for when Data Pump export (EXPDP) fails with the following ORA-00600 error seen in the alert log and also reported from the export log :

ORA-00600: internal error code, arguments: [unable to load XDB library], [], []

It may be that this article will solve for other situations where the error is seen but as the error
is quite general and can be see due to >1 reason there is no guarantee.  If in doubt please
raise a SR to ORACLE Support.

The following symptoms will be seen :-

a) EXPDP session/log will look something like :-

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

Starting "xx"."SYS_EXPORT_SCHEMA_01": gsa/********
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 11.16 GB
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/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31671: Worker process DW01 had an unhandled exception.
ORA-00600: internal error code, arguments: [unable to load XDB library], [], []
ORA-06512: at "SYS.KUPW$WORKER", line 1342
ORA-06512: at line 2

Job "xx"."SYS_EXPORT_SCHEMA_01" stopped due to fatal error at 11:03:15



b) The ORA-00600 trace will contain the SQL :-

SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('CLUSTER_T',
'7')), KU$.OBJ_NUM ,KU$.SCHEMA_OBJ.NAME ,KU$.SCHEMA_OBJ.NAME ,'CLUSTER' ,KU$.SCHEMA_OBJ.OWNER_NAME FROM SYS.KU$_CLUSTER_VIEW KU$ WHERE NOT (BITAND (KU$.SCHEMA_OBJ.FLAGS,16)=16) AND KU$.SCHEMA_OBJ.OWNER_NAME=:SCHEMA1 AND NOT EXISTS (SELECT 1 FROM SYS.KU$NOEXP_TAB A WHERE A.OBJ_TYPE='CLUSTER' AND A.NAME= KU$.SCHEMA_OBJ.NAME AND A.SCHEMA=KU$.SCHEMA_OBJ.OWNER_NAME) AND NOT EXISTS (SELECT 1 FROM SYS.KU$NOEXP_TAB A WHERE A.OBJ_TYPE='SCHEMA' AND A.NAME=KU$.SCHEMA_OBJ.OWNER_NAME);

----- PL/SQL Call Stack -----
object line object
handle number name
c0000000b9a60d98 1050 package body SYS.DBMS_METADATA
c0000000b9a60d98 1256 package body SYS.DBMS_METADATA
c0000000b9a60d98 1583 package body SYS.DBMS_METADATA
c0000000b9a60d98 1891 package body SYS.DBMS_METADATA
c0000000b9a60d98 4224 package body SYS.DBMS_METADATA
c0000000b9ac55a0 2005 package body SYS.KUPW$WORKER
c0000000b9ac55a0 6854 package body SYS.KUPW$WORKER
c0000000b9ac55a0 1259 package body SYS.KUPW$WORKER
c0000000b0534cc0 2 anonymous block



c) ORA-00600 trace file call stack will be similar to :-

kgerinv


d) Environment variables have been reviewed against Note 351650.1
    but are considered to be valid.

CauseThe cause seems linked to some corrupted KU$ objects but how the database gets into this
position is unclear from the ORA-600 trace.



Solution

As the SYSDBA user, please run the following scripts :-

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn