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

今天使用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 <- kgeasnmierr <- sqmtbGetSharedData <- qmtLoadSharedData <- qmtbInit <- qmtInit <- qmtLookup <- qmtAddRef <- qmxtgrGetSchemaProp <- qmxtgrCheckMkXML <- qctoxXMLGetTypeInfo <- qctoxmlexval <- qctcopn <- qctsvcti <- qctcopn <- xtyopn <- kokvbwoc <- kokvaroid <- kkmevw <- kkmfcbvw <- kkmfcblo <- kkmpfcbk <- qcsprfro <- qcsprfro_tree <- qcsprfro_tree <- qcspafq <- qcspqb <- qcspqb <- qcsevw <- kkmevw <- kkmfcbvw <- kkmfcblo <- kkmpfcbk <- qcsprfro <- qcsprfro_tree <- qcsprfro_tree <- qcspafq <- qcspqb <- qcspqb <- qcspqb <- qcsevw <- kkmevw <- kkmfcbvw <- kkmfcblo <- kkmpfcbk <- qcsprfro <- qcsprfro_tree <- qcsprfro_tree <- qcspafq <- qcspqb <- qcspqb <- qcspqb <- qcspqb <- qcspqb <- qcspqb <- qcsevw <- kkmevw <- kkmfcbvw <- kkmfcblo <- kkmpfcbk <- qcsprfro <- qcsprfro_tree <- qcsprfro_tree <- qcspafq <- qcspqb <- kkmdrv <- opiSem <- opiDeferredSem <- opitca <- kksFullTypeCheck <- rpiswu2 <- kksSetBindType <- kksfbc <- opiexe <- opipls <- opiodr <- rpidrus <- skgmstack <- rpidru <- rpiswu2 <- rpidrv <- psddr0 <- psdnal <- pevm_OPND <- pfrinstr_OPND <- pfrrun_no_tool <- pfrrun <- plsql_run <- peicnt <- kkxexe <- opiexe <- kpoal8 <- opiodr <- kpoodr <- upirtrc <- kpurcsc <- kpuexecv8 <- kpuexec <- OCIStmtExecute <- kupprdp <- opirip <- opidrv <- sou2o <- opimai_real
<- main <- $START$

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 :-