背景

接到客户反馈，用户把生产NC数据库导出之后，在测试库无法成功导入。在导入过程中遇到错误被终止。错误代码是ORA-7445[kpodpals],由于提供的信息量比较少，刚开始没有头绪，这个问题处理起来还是挺麻烦的。

问题分析

步骤一：分析跟踪日志信息

通过对跟踪日志的分析，查看问题的故障点。通过分析跟踪日志，查找问题出现的原因。跟踪日志文件，内容具体如下：

Trace file D:\ORACLE\APP\diag\rdbms\nctest\nctest\trace\nctest_dw00_10036.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.2  
CPU                 : 48 - type 8664, 24 Physical Cores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total): Ph:41707M/130574M, Ph+PgF:75082M/163342M 
Instance name: nctest
Redo thread mounted by this instance: 1
Oracle process number: 34
Windows thread id: 10036, image: ORACLE.EXE (DW00)


*** 2023-03-28 09:11:53.362
*** SESSION ID:(1633.23) 2023-03-28 09:11:53.362
*** CLIENT ID:() 2023-03-28 09:11:53.362
*** SERVICE NAME:(SYS$BACKGROUND) 2023-03-28 09:11:53.362
*** MODULE NAME:(Data Pump Worker) 2023-03-28 09:11:53.362
*** ACTION NAME:(SYS_IMPORT_SCHEMA_02) 2023-03-28 09:11:53.362
 
KUPC: Setting remote flag for this process to FALSE
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x0] [PC:0x14575B408, kpodpals()+5174]

*** 2023-03-28 12:39:17.376
Incident 732343 created, dump file: D:\ORACLE\APP\diag\rdbms\nctest\nctest\incident\incdir_732343\nctest_dw00_10036_i732343.trc
ORA-07445: exception encountered: core dump [kpodpals()+5174] [ACCESS_VIOLATION] [ADDR:0x0] [PC:0x14575B408] [UNABLE_TO_READ] []

步骤二：通过故障代码的分析，查找ORACLE官方相关文档。

通过对跟踪日志的分析，我们发现ORACLE 报ORA-07445 [kpodpals()+5174]，我们这里就抓住ORA-07445 [kpodpals()+5174]不放，这种核心错误，一般99%是Oracle的BUG引起，通过Oracle的官方信息，果然发现了一篇文档：
ORA-7445 [kpodpals] During DataPump Import (文档 ID 1096837.1)
SYMPTOMS

You perform a DataPump import and this breaks with errors:
#> impdp system/password directory=dpu dumpfile=a_table.dmp table_exists_action=replace
Import: Release 10.2.0.1.0 - Production on Wednesday, 21 April, 2010 9:21:43
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** directory=dpu
dumpfile=a_table.dmp table_exists_action=replace
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Worker process DW01 died unexpectedly.
Job "SYSTEM"."SYS_IMPORT_FULL_01" stopped due to fatal error at 09:23:32
CAUSE

This is addressed in Bug 9626756. A no-name column "<space>" is included in the table definition.
The imported table is defined as:
create table a_table
(
id number,
" " varchar2(10), -- " " means "<one space>"
text varchar2(10)
);
SOLUTION

1. Don't use columns like "<space>" in the source database

- OR -

2. If a table has such columns, then exclude the table during import with:
exclude=table:\"IN ('A_TABLE')\"

原因就是有表的字段是空格，坑啊，居然有这么创建表的，接下来我们就要查询下我们系统中是否真的存在这样的表。

解决方案

步骤一：查询表字段

select * from (select OWNER,table_name,replace(column_name,' ','*') as AA from dba_tab_columns) where  AA like '%*%';

通过上述SQL语句，一查询果然有空格字段，带有空格字段的表，具体如上图所示。真是害死人啊。
步骤二：排除表重新导入
有两种方式解决：

1.在正式库中对表进行调整或者重建，

2.导入的时排除问题表，经过沟通决定采用第二种方法，排除表

impdp system/xxxxx DIRECTORY=dp full=y DUMPFILE=wzyfull20141205b_01.dmp logfile=impdp1209.log trace=4a0300 exclude=TABLE:\"IN \(\'NC65.1_20201031-19\'，\'NC65.A_TEMPV2\',\'NC65.A_TEMP_20201031\',\'NC65.A_TEMP_V2\'，\'NC65.A_TEMP_V3\'\)\",SCHEMA:\"IN\(\'SYS\',\'SYSTEM\',\'OUTLN\',\'MGMT_VIEW\',\'FLOWS_FILES\',\'MDSYS\',\'ORDSYS\',\'EXFSYS\',\'DBSNMP\',\'WMSYS\',\'WKSYS\',\'WK_TEST\',\'CTXSYS\',\'ANONYMOUS\',\'SYSMAN\',\'XDB\',\'WKPROXY\',\'ORDPLUGINS\',\'FLOWS_030000\',\'OWBSYS\',\'SI_INFORMTN_SCHEMA\',\'OLAPSYS\',\'SCOTT\',\'ORACLE_OCM\'\)\"

总结

1、添加日志跟踪文件是分析错误的重要途径。数据泵日志跟踪：通过在导出导入时，添加trace参数，产生跟踪日志文件

2、ORA-7445 [kpodpals]： Bug 9626756.在一个表中包含一个没有名字的全是空格的字段。