Oracle 11.2.0.4 Data Pump Restore of T_S_BIZ_LOG Failed with ORA-07445: Investigating a klxprParseRow Crash

#

Recently, I worked on an Oracle 11.2.0.4 database migration.

The source database used ASM, while the target was a standalone filesystem-based database. The goal was to restore a schema from the source database into a test database using Oracle Data Pump.

The tablespace mapping was:

USERS → YSSUCO

Most objects were imported successfully.

However, one table behaved very differently:

T_S_BIZ_LOG

Whenever Data Pump reached the data-loading stage for this table, the Data Pump Worker could crash directly.

This was not just a normal Data Pump error such as:

ORA-39083
ORA-31684
ORA-39151

Instead, the Oracle server process eventually produced:

ORA-07445
SIGSEGV

The trace eventually pointed to:

klxprParseRow()

Interestingly, a later Oracle Bug Fix list contains a bug with a matching function-level signature:

31670014
AIM ORA-7445 [KLXPRPARSEROW] - KLXPRPARSEROW

This article documents the investigation and the reasoning behind the final workaround.

1. Environment

#

The environment was approximately:

Oracle Database 11.2.0.4.0
Linux x86_64
64-bit

Source database:
gzdb

Target database:
gzdb

Source storage:
ASM

Target storage:
Standalone filesystem

The source database was exported with:

expdp "/ as sysdba" \
cluster=N \
dumpfile=gzdb_full-${vdate}.dmp \
full=y \
parallel=4 \
logfile=gzdb_full-${vdate}.log \
directory=expdpbak \
compression=all

The dump file used for the migration was:

gzdb_full-2026-09-17.dmp

The target import mapped:

gzdb
   ↓
gzdb

and:

USERS
   ↓
YSSUCO

2. The Initial Data Pump Import

#

The first import was executed with:

impdp "'/ as sysdba'" \
directory=BACKUP1 \
dumpfile=gzdb_full-2026-09-17.dmp \
logfile=20260922-1119.log \
schemas=gzdb \
remap_schema=gzdb:gzdb \
remap_tablespace=USERS:YSSUCO \
parallel=16 \
cluster=N \
exclude=STATISTICS

Several errors appeared during the import:

ORA-31684 USER already exists
ORA-39151
ORA-39083
ORA-02304

At first glance, these messages looked related to the overall restore failure.

However, later testing showed that they represented separate issues.

The most obvious one involved user-defined object types.

3. ORA-02304 and User-Defined TYPE OIDs

#

The source schema contained a number of custom Oracle types, including:

STR_SPLIT
MAP_OBJECT_N2N
MAP_OBJECT
FEE_ROW_TYPE
ROW_TYPE
OBJ_TABLE
PORT_LIST_TYPE
DAE_ROW_TYPE
gz_CONCAT_IM
MAP_OBJECT_CLOB
OBJ_PARAMS
SPLITTYPE
VARTABLETYPE2
VARTABLETYPE
T_MAP_OBJECT_N2N
T_MAP_OBJECT
T_FEE_TYPE
T_MAP_OBJECT_CLOB
TAB_PARAMS

Data Pump generated DDL containing OID clauses such as:

CREATE TYPE ...
OID '2A7B2DF7A6C13042E0630408A8C066D4'
...

A manually executed example such as:

CREATE TYPE TEST_OID
OID '2A7B2DF7A6C13042E0630408A8C066D4'
AS TABLE OF VARCHAR2(4000);

returned:

ORA-02304
invalid object identifier literal

The generated TYPE DDL was extracted through SQLFILE, and the:

OID '...'

clauses were removed.

The 19 custom types could then be created successfully.

This confirmed that the TYPE OID problem was real.

However, it turned out to be separate from the later klxprParseRow() crash.

4. The Real Crash: T_S_BIZ_LOG

#

The more serious problem was that Data Pump did not merely report a bad row.

A Data Pump Worker process actually crashed.

The trace file was:

orcl_dw00_15519.trc

The most important information included:

Oracle Database 11.2.0.4.0

and:

DW00
Data Pump Worker

The final exception was:

Exception [type: SIGSEGV, SI_KERNEL(general_protection)]
[ADDR:0x0]
[PC:0x1F22D68, klxprParseRow()+4516]

ORA-07445: exception encountered:
core dump [klxprParseRow()+4516]
[SIGSEGV]

This was no longer an ordinary SQL or Data Pump object-creation error.

The Oracle server process itself had encountered an invalid memory access.

5. Was Data Pump PARALLEL Too High?

#

At the time, the import was using:

PARALLEL=16

Therefore, the first suspicion was naturally:

Could the high Data Pump parallelism be causing Oracle 11.2.0.4 to crash?

The import was therefore reduced to a single worker.

The problematic table was imported separately:

impdp "'/ as sysdba'" \
directory=BACKUP1 \
dumpfile=gzdb_full-2026-09-17.dmp \
logfile=t_s_biz_log_restore_20260922.log \
tables=gzdb.T_S_BIZ_LOG \
remap_schema=gzdb:gzdb \
remap_tablespace=USERS:YSSUCO \
parallel=1 \
cluster=N

The important result was:

PARALLEL=1

still crashed.

The same:

klxprParseRow()

function appeared in the trace.

This substantially reduced the likelihood that:

PARALLEL=16

was the primary cause.

6. What Was Data Pump Actually Doing?

#

The trace contained SQL similar to:

INSERT /*+ APPEND PARALLEL("T_S_BIZ_LOG",1)+*/
INTO RELATIONAL("gzdb"."T_S_BIZ_LOG" NOT XMLTYPE)
...
SELECT ...
FROM "ET$0CEDD59B0001" KU$

The SQL also referenced:

C_LOG_DETAIL
C_PLAIN_CONTENT

This showed that the crash occurred during the table-data loading phase.

The approximate execution path was:

Data Pump
    ↓
TABLE_DATA
    ↓
Data Pump Worker
    ↓
Direct-path data loading
    ↓
T_S_BIZ_LOG
    ↓
klxprParseRow()
    ↓
SIGSEGV
    ↓
ORA-07445

This was different from:

table creation failure

and also different from:

index creation failure

or:

tablespace unavailable

7. What Makes T_S_BIZ_LOG Different?

#

The table was not a small ordinary business table.

It contained approximately:

2,260,121 rows

and two CLOB columns:

C_LOG_DETAIL
C_PLAIN_CONTENT

The largest observed values were approximately:

C_LOG_DETAIL
655 KB

C_PLAIN_CONTENT
7.6 MB

The source database statistics showed:

C_LOG_DETAIL non-NULL:
2,224,651

C_PLAIN_CONTENT non-NULL:
2,221,263

There were approximately:

990 rows

where:

C_PLAIN_CONTENT > 1 MB

and:

53 rows

where:

C_PLAIN_CONTENT > 7 MB

The overall characteristics were therefore:

2.2+ million rows
+
two BASICFILE CLOB columns
+
many large CLOB values
+
maximum CLOB size around 7.6 MB per row

This is a very different workload from a conventional VARCHAR2-heavy table.

8. Was the CLOB Data Corrupted?

#

This was one of the most important questions.

The table row count was checked:

SELECT COUNT(*)
FROM gzdb.T_S_BIZ_LOG;

The result was approximately:

2260121

The maximum LOB lengths were also checked:

SELECT
    MAX(DBMS_LOB.GETLENGTH(C_LOG_DETAIL)),
    MAX(DBMS_LOB.GETLENGTH(C_PLAIN_CONTENT))
FROM gzdb.T_S_BIZ_LOG;

The results were:

C_LOG_DETAIL
655438

C_PLAIN_CONTENT
7604238

There was no immediate evidence that the LOB segments themselves were corrupt.

Normal SQL queries could also read the data.

Therefore, it would be too strong to conclude:

The CLOB data was corrupted.

A more accurate conclusion is:

The data characteristics of this table appear to trigger an abnormal condition somewhere in the Oracle 11.2.0.4 Data Pump data-loading path.

That distinction is important.

9. The Most Important Experiment: Excluding T_S_BIZ_LOG

#

The most valuable experiment was to exclude the problematic table from the Schema import.

The rest of the schema was imported normally, while:

T_S_BIZ_LOG

was excluded.

For example:

DIRECTORY=BACKUP1
DUMPFILE=gzdb_full-2026-09-17.dmp
LOGFILE=gzdb_without_bizlog_20260922.log
SCHEMAS=gzdb
REMAP_SCHEMA=gzdb:gzdb
REMAP_TABLESPACE=USERS:YSSUCO
PARALLEL=16
CLUSTER=N
EXCLUDE=TABLE:"IN ('T_S_BIZ_LOG')"

The result was:

Schema restoration completed

There was no further:

DW00 SIGSEGV
ORA-07445
klxprParseRow()

This was the most useful A/B test in the entire investigation.

10. The Resulting Test Matrix

#

At this point, the problem could be narrowed down considerably.

This strongly suggests:

Not the entire dump
Not the entire schema
Not simply insufficient tablespace
Not simply excessive Data Pump parallelism
Not a general permission problem
Not all CLOB data

Instead, the evidence points toward:

T_S_BIZ_LOG
        ↓
Specific data characteristics
        ↓
Data Pump TABLE_DATA
        ↓
Oracle 11.2.0.4 internal processing
        ↓
klxprParseRow()
        ↓
SIGSEGV

11. A Potential Connection to Oracle Bug 31670014

#

This was the most interesting part of the investigation.

Searching for:

klxprParseRow Oracle

revealed an Oracle bug entry in a later release’s bug-fix list:

31670014
AIM ORA-7445 [KLXPRPARSEROW] - KLXPRPARSEROW

The function name matches the trace from this incident:

ORA-07445
[klxprParseRow()+4516]

The public bug-fix information therefore provides a strong function-level correlation.

However, this does not prove that the current 11.2.0.4 incident is exactly Bug 31670014.

12. Why Bug 31670014 Cannot Be Confirmed from Public Information Alone

#

There are several things that would need to be established before making that claim:

Affected Versions
Fixed Versions
Patch Availability
Backport Information
Required PSU/BP/RU
Workaround

Oracle’s internal bug information is often available through My Oracle Support rather than public documentation.

Therefore, the technically safer conclusion is:

The incident has a strong function-level similarity to Oracle Bug 31670014, which is described as AIM ORA-7445 [KLXPRPARSEROW] - KLXPRPARSEROW. However, the available public information is insufficient to prove that this specific Oracle 11.2.0.4 environment is affected by that exact bug or by a backport of it.

This distinction matters when documenting production incidents.

13. Data Pump + ORA-07445 Is Not Completely Unique

#

This was also not the first historical case involving:

impdp
+
ORA-07445

There are Oracle community reports involving Data Pump imports and ORA-07445 on various Oracle 11g versions.

Some historical cases involved differences between source and target Oracle versions.

Other cases eventually led to Oracle Support investigations and recommendations involving patches, upgrades, or alternative migration approaches.

Therefore:

Data Pump
+
Oracle 11g
+
ORA-07445

is not an entirely unprecedented combination.

However, each incident still needs to be investigated from its own trace and execution context.

14. What Does Oracle Say About ORA-07445?

#

Oracle describes ORA-07445 as an operating-system-level exception encountered by an Oracle process.

The error is associated with situations such as:

Bad Data
Severe Misconfiguration
Oracle Software Bugs

Oracle recommends investigating the associated:

alert.log
trace files
ADR diagnostic information
ORA-07445 arguments

One of the most useful pieces of information is the function name contained in the error:

ORA-07445:
[function_name()+offset]

For example, in this case:

[klxprParseRow()+4516]

That function name provides a much more useful direction than a generic Data Pump failure message.

15. Why the Normal Data Pump Log Was Not Enough

#

This was another important lesson.

The Data Pump log may only show something like:

Processing object type ...

or:

import job stopped due to fatal error

It may not clearly identify the exact internal Oracle function that crashed.

The real diagnostic information was in the Oracle trace directory:

$ORACLE_BASE/diag/rdbms/.../trace/

For this incident:

orcl_dw00_15519.trc

contained:

DW00
Data Pump Worker

as well as:

klxprParseRow()

and:

ORA-07445
SIGSEGV

The practical lesson is:

The Data Pump log tells you that the import failed. The Oracle trace often tells you where the database process actually crashed.

16. Why T_S_BIZ_LOG Is a Suspicious Workload

#

The table has several characteristics worth highlighting:

2.2+ million rows

Two:

CLOB

columns.

And one CLOB reaches approximately:

7.6 MB

There are also hundreds of large LOB values and roughly one thousand values exceeding 1 MB.

Oracle Data Pump has specialized processing paths for LOB and other complex data types.

Therefore, from an engineering perspective, this combination is worth investigating:

T_S_BIZ_LOG
+
Large CLOBs
+
Oracle 11.2.0.4
+
Data Pump TABLE_DATA
+
klxprParseRow()

However, this should not be interpreted as:

CLOB = Oracle bug

There is not enough evidence to make that statement.

The more defensible conclusion is that this particular combination of table structure, data characteristics, and Oracle version appears to trigger the failure.

17. The Final Recovery Strategy

#

Once it was demonstrated that:

The rest of the schema can be restored successfully

the most practical strategy became:

Data Pump
       ↓
Restore the schema
       ↓
Exclude T_S_BIZ_LOG
       ↓
Migrate T_S_BIZ_LOG separately

In other words:

Restore the schema structure
+
Restore all other objects
+
Handle the problematic table independently

18. T_S_BIZ_LOG Does Not Have to Be Migrated with Data Pump

#

The table can also be migrated through:

Database Link
+
INSERT ... SELECT

For example:

CREATE DATABASE LINK SRC_gzdb
CONNECT TO gzdb
IDENTIFIED BY "source_password"
USING 'source_tns_service';

Then verify the connection:

SELECT COUNT(*)
FROM gzdb.T_S_BIZ_LOG@SRC_gzdb;

If the connection works, the data can be migrated in batches.

For example:

INSERT INTO gzdb.T_S_BIZ_LOG
(
    C_IDEN,
    C_FUN_CODE,
    C_IDF_CODE,
    D_TRADE,
    C_PORT_CODE,
    C_ITEM_CODE,
    C_ITEM_NAME,
    C_RESULT,
    D_UPDATE,
    C_UPDATE_BY,
    C_UPDATE_TIME,
    C_LOG_DETAIL,
    C_PLAIN_CONTENT,
    C_FUNRELA_ID,
    C_DISPATCH_ID,
    C_START_TIME,
    C_END_TIME,
    C_MES_TEXT,
    C_TASK_CATEGORY,
    C_PROCESS_INST_ID,
    C_TASK_INST_ID,
    C_EXTRA_INFO,
    C_IP,
    C_USE_TIME,
    C_PLAN_CODE,
    C_ITEM_EXTRA_INFO,
    C_NODATA_TYPE
)
SELECT
    C_IDEN,
    C_FUN_CODE,
    C_IDF_CODE,
    D_TRADE,
    C_PORT_CODE,
    C_ITEM_CODE,
    C_ITEM_NAME,
    C_RESULT,
    D_UPDATE,
    C_UPDATE_BY,
    C_UPDATE_TIME,
    C_LOG_DETAIL,
    C_PLAIN_CONTENT,
    C_FUNRELA_ID,
    C_DISPATCH_ID,
    C_START_TIME,
    C_END_TIME,
    C_MES_TEXT,
    C_TASK_CATEGORY,
    C_PROCESS_INST_ID,
    C_TASK_INST_ID,
    C_EXTRA_INFO,
    C_IP,
    C_USE_TIME,
    C_PLAN_CODE,
    C_ITEM_EXTRA_INFO,
    C_NODATA_TYPE
FROM gzdb.T_S_BIZ_LOG@SRC_gzdb
WHERE ORA_HASH(C_IDEN, 19) = 0;

COMMIT;

The batches can then be processed using:

0
1
2
...
19

for a total of 20 batches.

If individual batches are still too large, the table can be divided into 40 or more buckets.

19. Why DB Link + INSERT Is Worth Testing

#

The important point is that this approach does not use exactly the same Data Pump data-loading path.

The failing path is approximately:

Data Pump Worker
        ↓
TABLE_DATA
        ↓
Direct-path loading
        ↓
APPEND
        ↓
klxprParseRow()
        ↓
SIGSEGV

A normal SQL migration uses a different execution path:

INSERT INTO ...
SELECT ...
FROM ...@DBLINK;

If the complete:

2,260,121 rows
+
two CLOB columns

can be transferred successfully through DB Link and ordinary SQL, this provides additional evidence that the data itself is readable and that the failure is concentrated in the Data Pump loading path.

That is a much more useful diagnostic result than simply trying Data Pump repeatedly.

20. Do Not Start by Moving All 2.2 Million Rows

#

The first migration test should be deliberately small.

For example:

INSERT INTO gzdb.T_S_BIZ_LOG
SELECT *
FROM (
    SELECT *
    FROM gzdb.T_S_BIZ_LOG@SRC_gzdb
    WHERE ORA_HASH(C_IDEN, 19) = 0
)
WHERE ROWNUM <= 1000;

COMMIT;

First validate:

1,000 rows
+
CLOB data
+
DB Link
+
target table

Then move to:

10,000

then:

100,000

and finally perform the full batches.

Large CLOB migrations can generate substantial:

UNDO
REDO
TEMP
Network traffic
LOB writes

A single massive transaction is therefore not necessarily desirable.

21. A Practical Investigation Workflow for Similar Cases

#

For future Data Pump failures, a useful sequence is:

1. Check the alert log

#

grep -i "ORA-07445" alert*.log

2. Locate recent trace files

#

find $ORACLE_BASE/diag -name "*.trc" -mmin -60

3. Find the ORA-07445 function

#

Look for:

ORA-07445:
[function_name()+offset]

In this case:

[klxprParseRow()+4516]

4. Inspect the current SQL

#

Look for information such as:

SQL_ID
TABLE_NAME
MODULE
ACTION

5. Reduce Data Pump parallelism

#

Use:

PARALLEL=1

not necessarily as the final solution, but as a diagnostic test.

6. Import the suspected table independently

#

For example:

impdp ... tables=gzdb.T_S_BIZ_LOG parallel=1

7. Exclude the suspected table

#

If the rest of the schema completes successfully after excluding it, the problem is much more narrowly defined.

8. Use an alternative migration path

#

Possible alternatives include:

Database Link
+
INSERT SELECT

or:

SQL*Loader

or an intermediate data file.

22. The Most Important Lesson

#

One of the easiest mistakes in Oracle migration work is assuming:

A Data Pump error means the source data itself is corrupted.

That is not necessarily true.

For serious errors such as:

ORA-00600
ORA-07445
SIGSEGV
core dump

if ordinary SQL can read the source data while Data Pump crashes during the loading phase, Oracle internal software defects become an important possibility.

This particular case is a good example:

2.2+ million rows
+
two CLOB columns
+
maximum CLOB around 7.6 MB
+
Oracle 11.2.0.4
+
Data Pump
+
klxprParseRow
+
SIGSEGV

The decisive experiment was simply:

EXCLUDE T_S_BIZ_LOG

After excluding the problematic table, the rest of the schema could be restored successfully.

The problematic table could then be handled separately.

23. Final Conclusion

#

The incident did not ultimately look like a conventional:

ORA-01653
Tablespace full

or:

ORA-39083
Object creation failure

Instead, the observed failure path was:

Data Pump Worker
        ↓
TABLE_DATA
        ↓
T_S_BIZ_LOG
        ↓
klxprParseRow()
        ↓
SIGSEGV
        ↓
ORA-07445

Reducing:

PARALLEL=16

to:

PARALLEL=1

did not resolve the crash.

Excluding:

T_S_BIZ_LOG

allowed the rest of the schema to be restored successfully.

The most reasonable current assessment is:

Oracle 11.2.0.4 Data Pump appears to encounter an internal exception while processing this particular table, which contains two large BASICFILE CLOB columns. Public Oracle bug-fix information also contains Bug 31670014, described as AIM ORA-7445 [KLXPRPARSEROW] - KLXPRPARSEROW, which has a strong function-level similarity to the observed klxprParseRow() crash. However, public information alone is insufficient to prove that this incident is exactly Bug 31670014 or a specific backport of that bug.

The practical recovery strategy is therefore:

Restore everything that Data Pump can handle
                    ↓
Exclude the problematic table
                    ↓
Migrate the table separately
                    ↓
Validate row counts and LOB data

This approach is not as elegant as a single complete Data Pump import.

But database recovery is ultimately about completing the migration safely, not about forcing every object through the same mechanism.

A single problematic table should not hold the entire schema hostage.

For older Oracle releases such as:

11.2.0.4

isolating the failing object and switching to a different migration path can often be much more practical than repeatedly retrying the same failing Data Pump operation.

#

References

#

1. Oracle documentation on ORA-07445 and diagnostic information.
2. Oracle community discussions involving Data Pump and ORA-07445.
3. Oracle 19.10 bug-fix information listing Bug 31670014: AIM ORA-7445 [KLXPRPARSEROW] - KLXPRPARSEROW
4. Oracle Database 11g Data Pump documentation.