数据泵导入时出现ORA-600(klaprs_11)错误

今天在使用数据泵导入的时候碰到了这个ORA-600错误。

 

 

执行的导入命令和对应的错误信息如下：

-bash-3.00$ impdp system/sjsystem15js directory=DMP_DIR dumpfile=jsdemo_091226.dp logfile=jsdemo_091226_imp.log remap_schema=bjsq_demo_ndmain:jssq_demo_ndmain,bjsq_demo_trade:jssq_demo_trade remap_tablespace=bjsq:jssqtbs

Import: Release 10.2.0.3.0 - 64bit Production on Saturday, 26 December, 2009 15:20:51

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
ORA-39002: invalid operation
ORA-31694: master table "SYSTEM"."SYS_IMPORT_FULL_01" failed to load/unload
ORA-02354: error in exporting/importing data
ORA-39776: fatal Direct Path API error loading table "SYSTEM"."SYS_IMPORT_FULL_01"
ORA-00600: internal error code, arguments: [klaprs_11], [], [], [], [], [], [], []

错误居然发生在一开始的建立导入工作表SYS_IMPORT_FULL_01处，看来问题比较奇怪。检查了一下对应的日志，错误信息和上面的基本一致。

检查了一下alert文件，发现了同样的ORA-600错误：

Sat Dec 26 15:20:59 2009
Errors in file /data/oracle/admin/jiangsu/bdump/jiangsu_dw01_16742.trc:
ORA-00600: internal error code, arguments: [klaprs_11], [], [], [], [], [], [], []

检查对应的trace文件：

bash-3.00$ more /data/oracle/admin/jiangsu/bdump/jiangsu_dw01_16750.trc
/data/oracle/admin/jiangsu/bdump/jiangsu_dw01_16750.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
ORACLE_HOME = /data/oracle/product/10.2
System name:    SunOS
Node name:      jsdb
Release:        5.10
Version:        Generic_118833-33
Machine:        sun4u
Instance name: jiangsu
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 16750, image: oracle@jsdb (DW01)

*** ACTION NAME:(SYS_IMPORT_SCHEMA_01) 2009-12-26 15:24:32.398
*** MODULE NAME:(Data Pump Worker) 2009-12-26 15:24:32.398
*** SERVICE NAME:(SYS$USERS) 2009-12-26 15:24:32.398
*** SESSION ID:(158.37252) 2009-12-26 15:24:32.398
*** 2009-12-26 15:24:32.398
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [klaprs_11], [], [], [], [], [], [], []
Current SQL statement for this session:
INSERT /*+ SYS_DL_CURSOR */ INTO RELATIONAL("SYSTEM"."SYS_IMPORT_SCHEMA_01") ("PROCESS_ORDER","DUPLICATE","DUMP_FILEID","DUMP_POSITI
ON","DUMP_LENGTH","DUMP_ALLOCATION","COMPLETED_ROWS","ERROR_COUNT","ELAPSED_TIME","OBJECT_TYPE_PATH","OBJECT_PATH_SEQNO","OBJECT_TYP
E","IN_PROGRESS","OBJECT_NAME","OBJECT_LONG_NAME","OBJECT_SCHEMA","ORIGINAL_OBJECT_SCHEMA","PARTITION_NAME","SUBPARTITION_NAME","FLA
GS","PROPERTY","COMPLETION_TIME","OBJECT_TABLESPACE","SIZE_ESTIMATE","OBJECT_ROW","PROCESSING_STATE","PROCESSING_STATUS","BASE_PROCE
SS_ORDER","BASE_OBJECT_TYPE","BASE_OBJECT_NAME","BASE_OBJECT_SCHEMA","ANCESTOR_PROCESS_ORDER","DOMAIN_PROCESS_ORDER","PARALLELIZATIO
N","UNLOAD_METHOD","GRANULES","SCN","GRANTOR","NAME","VALUE_T","VALUE_N","IS_DEFAULT","FILE_TYPE","USER_DIRECTORY","USER_FILE_NAME",
"FILE_NAME","EXTEND_SIZE","FILE_MAX_SIZE","PROCESS_NAME","LAST_UPDATE","WORK_ITEM","OBJECT_NUMBER","COMPLETED_BYTES","TOTAL_BYTES","
METADATA_IO","DATA_IO","CUMULATIVE_TIME","PACKET_NUMBER","OLD_VALUE","SEED","LAST_FILE","USER_NAME","OPERATION","JOB_MODE","CONTROL_
QUEUE","STATUS_QUEUE","REMOTE_LINK","VERSION","DB_VERSION","TIMEZONE","STATE","PHASE","GUID","START_TIME","BLOCK_SIZE","METADATA_BUF
FER_SIZE","DATA_BUFFER_SIZE","DEGREE","PLATFORM","ABORT_STEP","INSTANCE","XML_CLOB") VALUES (NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,N
ULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NUL
L,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
3b7490240        54  package body SYS.KUPD$DATA_INT
4ab1bed70      1324  package body SYS.KUPD$DATA
52029c950     10716  package body SYS.KUPW$WORKER
52029c950      3687  package body SYS.KUPW$WORKER
52029c950      6896  package body SYS.KUPW$WORKER
52029c950      1259  package body SYS.KUPW$WORKER
4c3c46730         2  anonymous block
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
ksedmp()+744         CALL     ksedst()             000000840 ?
                                                   FFFFFFFF7FFEAC7C ?
                                                   000000000 ?
                                                   FFFFFFFF7FFE7770 ?
                                                   FFFFFFFF7FFE64D8 ?
                                                   FFFFFFFF7FFE6ED8 ?
kgerinv()+200        PTR_CALL 0000000000000000     000105C00 ? 105F06924 ?
                                                   105F06000 ? 000105F06 ?
                                                   000105C00 ? 105F06924 ?
kgeasnmierr()+28     CALL     kgerinv()            105F012D8 ? 000000000 ?
                                                   105C91AE0 ? 000000000 ?
                                                   FFFFFFFF7FFEB120 ?
                                                   000001430 ?
klaprs()+5260        CALL     kgeasnmierr()        105F012D8 ? 10613D640 ?
                                                   105C91AE0 ? 000000000 ?
                                                   000105C00 ? 000105C91 ?
kpodpls()+632        CALL     klaprs()             105F00F98 ?
                                                   FFFFFFFF78EB8390 ?
                                                   FFFFFFFF78E35493 ?
                                                   000000002 ? 000009B6E ?
                                                   FFFFFFFF78EBB748 ?
opiodr()+1548        PTR_CALL 0000000000000000     000000001 ? 10512A8D8 ?
                                                   000004200 ? 00000012C ?
                                                   000000000 ?
                                                   FFFFFFFF78EB93A8 ?
kpoodr()+444         CALL     opiodr()             1051BA480 ? 000000081 ?
                                                   105F011C0 ? 000000001 ?
                                                   FFFFFFFF79B266D8 ?
                                                   000105F03 ?
upirtrc()+1164       PTR_CALL 0000000000000000     FFFFFFFF79479598 ?
                                                   000000081 ?
                                                   FFFFFFFF7FFEEED8 ?
                                                   FFFFFFFF7FFF6AE8 ?
                                                   000000000 ?
                                                   FFFFFFFF796B00B0 ?

从trace文件中看不出什么有意义的东西，感觉可能是Oracle的bug，于是查询了一下metalink，结果在文档ID 743483.1中发现了相关的描述。

Oracle认为导致这个错误的原因可能是DMP文件被损坏。这个说明是合理的，否则很难解释为什么Oracle在建立导入工作表的时候都会出现错误。而且根据这个错误描述，回想到当时执行的一个操作：在导出操作执行完以后，本打算用gzip压缩一下，不过压缩刚开始执行就放弃了这个想法，于是中止了压缩操作。看来很可能是这个原因导致了错误。

尝试重新导出DMP文件，直接ftp到目标站点，再次执行同样的导入操作，导入顺利完成，看来果然是由于DMP文件损坏导致的。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-623701/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-623701/