换了内存条 oracle字符集出问题了,做Oracle数据库迁移，碰上了灵异的字符集问题，懵了...

以下是我的问题：

做Oracle数据库迁移，碰上了灵异的字符集问题，懵了

关键字: oracle字符集, 数据库迁移

从前天开始就出现这个问题，也上网找了很多资料，原理貌似正确，但实践却出现了意想不到的问题

先说一下环境

源数据库

OS：Windows Server 2003

Database：Oracle Database Enterprise Edition 10.2.0.1 for Windows

目标数据库

OS：Fedora Core 9

Database：Oracle Database Enterprise Edition 10.2.0.1 for Linux

再说过程

1.由于本人的机器是双系统，所以先切到Windows 使用远程桌面连到那个装着Server 2003的服务器exp 出来一个test.dmp文件,然后用ipmsg发回本机。

2.重启本机，进入FC9,挂上Windows的FAT32分区，将test.dmp文件复制到FC的oracle用户下面的目录中。

3.然后是就是打开终端imp，输入文件名和buffer size，一敲回车，就出现了下面的内容

# Export file created by EXPORT:V10.01.00 via conventional path

# import done in US7ASCII character set and AL16UTF16 NCHAR character set

# import server uses ZHS16GBK character set (possible charset conversion)

# export client uses ZHS16GBK character set (possible charset conversion)

4.然后如果继续导入的话，就是所有的中文全部变成了乱码

接着说我试过的解决方案

1.google一把，发现有很多人都碰上了类似的问题，大家都一致认为这个问题出现的原因无怪乎跟下面三处地方的字符集有关

# Oracle服务器端

# Oracle客户端

# dmp文件

2.好了，很多人说只要这上面这三个地方的charset一样就可正常导入 ,那么怎么检测呢，很多人说的方法也都是相同的

检测Oracle服务端的charset;

select userenv('language') from dual;

我用这个sql检测出来的结果是

Windows Server 2003：SIMPLIFIED CHINESE_CHINA.ZHS16GBK

Fedora Core 9：AMERICAN_AMERICA.ZHS16GBK

因为这两个明显不一样，正怀疑中，又有很多人说其实这个字符集只看这个查询出来的最后一个，这里都是ZHS16GBK，所以都一样，继续检查Client端

检测Oracle客户端的charset;

Windows Server 2003：HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/NLS_LANG 这个值看是多少，很多说如果最后一个和其它的一样也算通过， 不过我要说的是相信各位在Windows上安装Oracle10g后这个值应该和我的一样吧，都是NA,所以我赶快改正过来，改正后的值是SIMPLIFIED CHINESE_CHINA.ZHS16GBK,这样就和Windows Server的一样了。

Fedora Core 9：又有很多人说linux下要echo $NLS_LANG,这个变量的值要和linux Oracle 服务器端的一样，我检查了一下，是空的，就export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

OK，这下好了，两边的按理说都应该正确了

检测dmp文件的charset;

Windows：有很多说要用UE-32打开dmp文件检查第二和第三个字节，然后将这两个字节的16进制的字符放入一个sql中执行，比如查看到第二个字符是03，第三个字符是54,那么就执行

#select nls_charset_name(to_number('0354','xxxx')) from dual;

出来的结果就应该是ZHS16GBK

这里我的结果是0354,所以自然也就是ZHS16GBK

Fedora Core 9：在linux检测这两个字节就不是这么容易了，需要使用一个命令

cat /home/oracle/test.dmp |od -x|head -1|awk '{print $2 $3}'|cut -c 3-6

可问题就出在这个上命令了，同样的文件，我检测到的竟然是0345,不是之前在Windows上的0354

天哪,没道理了，还有这种事情!

3.然后，我就没什么可说了，这时如果继续导入的话，就出现下面的

# Export file created by EXPORT:V10.01.00 via conventional path

# import done in ZHS16GBK character set and AL16UTF16 NCHAR character set

貌似少了几行，但是继续操作的话还是多么好看的中文乱码。

特别希望有人出来真正解释一下所发生的一切

[本帖最后由 greenbamboo1111 于 2008-7-16 15:14 编辑]