Impdp因致命错误终止 ORA-7445 [kpodpals]

背景

接到客户反馈,用户把生产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 (selectOWNER,table_name,replace(column_name,' ','*') asAAfromdba_tab_columns) whereAAlike'%*%';

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

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

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

impdpsystem/xxxxxDIRECTORY=dpfull=yDUMPFILE=wzyfull20141205b_01.dmplogfile=impdp1209.logtrace=4a0300exclude=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.在一个表中包含一个没有名字的全是空格的字段。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/270202.html<

(0)
管理的头像管理
上一篇2025-05-07 17:14
下一篇 2025-05-07 17:15

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注