Data Pump Import (IMPDP) Fails With Error: ORA-39183: internal error -19 ocurred during decompression phase 2 (Doc ID 2092469.1)

To BottomTo Bottom

In this Document

  Symptoms
  Changes
  Cause
  Solution

 

APPLIES TO: 

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Information in this document applies to any platform.
***Checked for relevance on 31-May-2017***

NOTE: In the document content below, the user information and data used represents fictitious data .Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner. 

SYMPTOMS

On : 11.2. version, Data Pump Import (IMPDP)

When attempting to perform an import of a dumpfile set, the following errors occur.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "user"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "<user>"."SYS_IMPORT_FULL_01":user/******** full=y directory=TEST_DATA_PUMP dumpfile=TEST_20151222_%U.dmp logfile=TEST_20151223.log parallel=8
Processing object type DATABASE_EXPORT/TABLESPACE
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.LOAD_METADATA [SELECT process_order, flags, xml_clob, NV
L(dump_fileid, :1), NVL(dump_position, :2), dump_length, dump_allocation, NVL(value_n, 0), grantor, object_row,
object_schema, object_long_name, partition_name, subpartition_name, processing_status, processing_state, base_ob
ject_type, base_object_schema, base_object_name, base_process_order, property, size_estimate, in_progress, origi
nal_object_schema, original_object_name, creation_level, object_int_oid FROM "user"."SYS_IMPORT_FULL_01" WHER
E process_order between :3 AND :4 AND duplicate = 0 AND processing_state NOT IN (:5, :6, :7) ORDER BY process_o
rder]
ORA-39183: internal error -19 ocurred during decompression phase 2
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 9001
----- PL/SQL Call Stack -----
object line object
handle number name
0x10eadc180 20462 package body SYS.KUPW$WORKER
0x10eadc180 9028 package body SYS.KUPW$WORKER
0x10eadc180 4185 package body SYS.KUPW$WORKER
0x10eadc180 9725 package body SYS.KUPW$WORKER
0x10eadc180 1775 package body SYS.KUPW$WORKER
0x10eae1cb0 2 anonymous block
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.LOAD_METADATA [SELECT process_order, flags, xml_clob, NV
L(dump_fileid, :1), NVL(dump_position, :2), dump_length, dump_allocation, NVL(value_n, 0), grantor, object_row,
object_schema, object_long_name, partition_name, subpartition_name, processing_status, processing_state, base_ob
ject_type, base_object_schema, base_object_name, base_process_order, property, size_estimate, in_progress, origi
nal_object_schema, original_object_name, creation_level, object_int_oid FROM "user"."SYS_IMPORT_FULL_01" WHER
E process_order between :3 AND :4 AND duplicate = 0 AND processing_state NOT IN (:5, :6, :7) ORDER BY process_o
rder]
ORA-39183: internal error -19 ocurred during decompression phase 2
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 9001

 

The file has not been FTP'd so there is no file transfer corruption.

CHANGES

 

CAUSE

The cause for the error was due to an inconsistent dumpfile set
 
As observed by the 'ls -la' output, we see the first file is much later than the rest of the dumpfile set.

ora11g@<host_name>:11gR2.0.2>ls -la
total 353583752
drwxr-xr-x 2 1000 2072 4096 Dec 23 15:22 .
drwxr-xr-x 4 ora11g dba 4096 Nov 16 15:12 ..
-rw-rw-rw- 1 1000 2072 240870 Dec 22 16:08 TEST_20151222.log
-rw-rw-rw- 1 1000 2072 103408259072 Dec 22 17:44 TEST_20151222_01.dmp  <<<<<<<<<<<<-----------------Timestamp long after export completed.
-rw-rw-rw- 1 1000 2072 15051726848 Dec 22 15:59 TEST_20151222_02.dmp
-rw-rw-rw- 1 1000 2072 15680311296 Dec 22 15:59 TEST_20151222_03.dmp
-rw-rw-rw- 1 1000 2072 13700804608 Dec 22 15:59 TEST_20151222_04.dmp
-rw-rw-rw- 1 1000 2072 15125839872 Dec 22 15:59 TEST_20151222_05.dmp
-rw-rw-rw- 1 1000 2072 18542436352 Dec 22 16:08 TEST_20151222_06.dmp
-rw-rw-rw- 1 1000 2072 15964495872 Dec 22 15:59 TEST_20151222_07.dmp
-rw-rw-rw- 1 1000 2072 292630528 Dec 22 16:07 TEST_20151222_08.dmp
-rw-r----- 1 1000 2072 3110 Dec 23 15:22 TEST_20151223_import.log
-rw-rw-rw- 1 1000 2072 3109 Dec 23 15:22 nohup.out


But according to the export log, we see that the export ended at 16:05:51:

Export: Release 11.2.0.2.0 - Production on Tue Dec 22 14:51:56 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
;;;
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "user"."SYS_EXPORT_FULL_02": user/******** full=yes directory=TEST_DATA_PUMP_ dumpfile=TEST_20151222_%U.dmp logfile=TEST_20151222.log parallel=8
...
...
...
Master table "user"."SYS_EXPORT_FULL_02" successfully loaded/unloaded
******************************************************************************
Dump file set for USER.SYS_EXPORT_FULL_02 is:
/......../......./TEST/DATA_PUMP/TEST_20151222_01.dmp
/......../......./TEST/DATA_PUMP/TEST_20151222_02.dmp
/......../......./TEST/DATA_PUMP/TEST_20151222_03.dmp
/......../....../TEST/DATA_PUMP/TEST_20151222_04.dmp
/......../....../TEST/DATA_PUMP/TEST_20151222_05.dmp
/......../....../TEST/DATA_PUMP/TEST_20151222_06.dmp
/......../....../TEST/DATA_PUMP/TEST_20151222_07.dmp
/......../....../TEST/DATA_PUMP/TEST_20151222_08.dmp
Job "user"."SYS_EXPORT_FULL_02" successfully completed at 16:05:51

 
This tells us the first export file this dumpfile set "TEST_20151222_01.dmp" was overwritten.
 

SOLUTION

Run a new export to generate a consistent dump file.

*** NOTE: Consider a dumpfile set name that may be more unique than the instance name and date to avoid another export utilizing the same name structure ***