【字符集续】IMP-00037: Character set marker unknown所引起的

 

最近好像与字符集耗上了，前几天刚刚处理了测试哥们那边数据库汉字显示乱码的问题，不用多想，初步判断为client与server字符集设置不一致导致解析时，出现异常。Linux/unix下比较好办，修改相关用户的环境变量即可。Windows下稍微麻烦一点，由于该client以前安装过多次ORACLE，而且出现多个ORACLE_HOME，导致修改NLS_LANG变量值，常常是不生效，后来直接通过添加系统级别环境变量NLS_LANG即可，而且该变量的优先级高于注册表中的，所以就不需要去深入研究那几个HOME的问题了。小问题折腾人啊。

今天又遇到一个比较低级的问题，也是由于别人的误导，导致多多花费了半小时来研究这个问题。现场技术服务员提交一个比较紧急的问题，说是可以昨天刚刚exp的dmp文件，不能导入到数据库中，其中不涉及客户端，所有操作都在同一台机器上进行。初步判断过滤掉文件在传输过程中损坏的可能性。由于dmp文件本身不大，所以就让他给我传递一份回来，在本地相同环境下测试：

 

SQL> create user test identified by test default tablespace hhris;

 

User created.

 

SQL> grant dba to test;

 

Grant succeeded.

 

SQL> exit

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.4.0 - Production

 

-bash-2.05b$ ls -lrt

??? 96196

drwxr-xrwx   51 oracle   oinstall     4096 2008-01-06  orahome

drwxrwxrwx    8 oracle   oinstall     4096 2008-01-06  orabase

drwxr-xr-x    2 root     root         4096 2008-03-21  orascript

-rw-r--r--    1 oracle   oinstall 14188214 Nov 17 10:38 hhris.dmp

-bash-2.05b$ imp test/test file=hhris.dmp fromuser=hhris touser=test buffer=20480000 log=imp.log

 

Import: Release 9.2.0.4.0 - Production on Mon Nov 17 10:38:39 2008

 

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

 

 

Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.4.0 - Production

 

IMP-00037: Character set marker unknown

IMP-00000: Import terminated unsuccessfully

 

在imp的过程中遇到imp-00037错误，表示imp遇到一个数据库不能识别的字符集。于是就查看了dmp文件中字符集的表示（dmp文件中第二、三字节表示字符集）

 

-bash-2.05b$ cat hhris.dmp|od -x | head

 

0000000 8b1f 0808 a190 4918 0300 6868 6972 2e73

0000020 6d64 0070 5cec 73ff c71b 5f75 2092 9d04

0000040 f928 5c4b d3b7 dd4e ba1b c52d a48e e000

0000060 9117 ebb4 1019 9238 0237 c870 51dd f316

0000100 0b0b 2711 3611 b009 1800 9e49 90fe fe99

0000120 fd17 b14d 78e3 9e32 a454 5144 a8a2 a4af

0000140 90be 25ac a259 c4c8 1b8d b13b 7f55 358f

0000160 ed76 6e46 beac bb77 dc07 1037 54f4 954e

0000200 ac19 dc05 def1 ede7 7dbe defb b7db 0b7b

0000220 91d7 611a 424f d592 ddae cefe fe1d 0ee0

 

通过将1F08转化成十进制为7944，查看相应的字符集

 

SQL> select nls_charset_name(7944) from dual;

 

N

-

 

在数据库中没有找到匹配的字符集。

此时陷入死角，难道exp出来的时候就有问题，不过由于找不到当时的exp日志，无法查阅。于是又找到前一天的dmp文件，发现还是相同的问题。当然突然想到，是不是文件本身有问题呢？

于是执行了以下动作，一切变得明朗起来：

 

-bash-2.05b$ file hhris.dmp

hhris.dmp: gzip compressed data, was "hhris.dmp", from Unix

 

原来这个dmp文件是一个压缩文件，这就难怪了。所以其它问题一切都迎刃而解了。

 

这里需要说明的两点：

1、              在exp的结果后做了一个gzip，但是文件名还是dmp，容易给人误导，这就是设计时不太合理的地方。

 

2、              当遇到问题在DB级不能得到正确解释时，还是需要回过头来，从OS级下手。

 

记录下来，便于个人查阅！