數據泵導入時出現ORA-600 klaprs_11錯誤該怎么辦

數據泵導入時出現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文件損壞導致的。

關于數據泵導入時出現ORA-600 klaprs_11錯誤該怎么辦問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。