背景

接到客戶反饋，用戶把生產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_actinotallow=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_actinotallow=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.在一個表中包含一個沒有名字的全是空格的字段。