标签归档：IMP-00028

解决imp导入数据报IMP-00098错误

发表于 2014 年 3 月 16 日 由 惜分飞

晚上十点多，准备睡觉了，一个朋友在qq上找到我,说他们数据库imp异常,希望我帮忙看看
大概情况
使用exp/imp升级并迁移数据库从win 10.2.0.1 升级到linux 11.2.0.3 由于硬盘空间不够，使用exp把win上面数据导出来，格式化掉win的数据文件所在硬盘格式化并加入到linux系统中(也就是说，故障之时，只有dmp文件，没有了数据文件）,因为原库没有了,dmp又报错,所以担心了起来.
imp报错信息

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Tes

Export file created by EXPORT:V10.02.01 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
export client uses US7ASCII character set (possible charset conversion)
. . importing table                "ART_T_ARCTYPE"          0 rows imported
. . importing table                "ART_T_ARTICLE"          0 rows imported
……
. . importing table            "EVT_T_ACCEPT_CODE"          1 rows imported
. . importing table            "EVT_T_ACCEPT_FLOW"
 illegal lob length marker 51166
 bytesread = 00000000000
 TABLE =EVT_T_ACCEPT_FLOW   EVT_T_ACCEPT_FLOW
IMP-00098: INTERNAL ERROR: impgst2
IMP-00028: partial import of previous table rolled back: 680071 rows rolled back
IMP-00008: unrecognized statement in the export file:
  ??????????????????
IMP-00008: unrecognized statement in the export file:
  .:
IMP-00008: unrecognized statement in the export file:
  $;
IMP-00008: unrecognized statement in the export file:
  ||$
…………

这里可以知道数据库exp的客户端是版本是10.2.0.1,使用编码是US7ASCII,但是导入的库编码是ZHS16GBK

exp日志信息

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)

EXP-00091: Exporting questionable statistics.
. . exporting table              EVT_T_ACCEPT_FLOW    3470071 rows exported
. . exporting table             EVT_T_ACCEPT_FLOW1    2707606 rows exported
……
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully with warnings.

这里我们可以知道数据库编码是ZHS16GBK,exp客户端编码为US7ASCII,因此到导出过程中发生了一次由ZHS16GBK到US7ASCII的编码转换

检查新库发现,其db编码为ZHS16GBK,新库的NLS设置为:nls_lang=AMERICAN_AMERICA.ZHS16GBK
整个导出流程是:db编码为ZHS16GBK的数据库被客户端编码为US7ASCII的exp导出,然后被编码为ZHS16GBK的imp导入到db编码为ZHS16GBK的数据库中

故障可能性定位
1.可能在从ZHS16GBK到US7ASCII的编码转换中发生数据异常,也就是说dmp文件本身异常(我们最不希望出现的结果)
2.由于数据库导出过场会发生编码转换(ZHS16GBK->US7ASCII),而导入过程未发生编码转换(ZHS16GBK->ZHS16GBK),从而出现异常

分析并解决
1. 使用dul扫描dmp文件发现汉字都能够识别,而且exp成功的记录条数在dul扫描中都完全正常恢复出来,证明dmp文件是正常的
2. 基于dmp文件正常,编码转换的过程,得出结论在该库的imp过程中设置nls_lang=AMERICAN_AMERICA.US7ASCII问题应该就可以正常解决.果不其然,设置了NLS_LANG之后imp导入数据OK

得出结论
1. 做升级,迁移尽快保留多一份数据,这次吓得不轻
2. exp/imp最好前后客户端编码一致,否则可能被转换晕
如果遭遇真的dmp损坏情况,类似:IMP-00098: INTERNAL ERROR: impgst2,可以联系我们,提供专业处理

发表在 逻辑备份/恢复 | 标签为 , | 2 条评论