【EXP/IMP】EXP/IMP过程中的字符集问题

63 阅读 0 评论 42 点赞

我是靠谱客的博主微笑航空，最近开发中收集的这篇文章主要介绍【EXP/IMP】EXP/IMP过程中的字符集问题，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1. 问题描述：

数据库之间的数据迁移是一个很常见的作业，EXP/IMP工具是一个常用的数据迁移及转化工具，因其导出文件具有平台无关性，所以在跨平台迁移中，最为常用。但在实际操作过程中，涉及到源数据库，客户端，目标数据库三方面的字符集问题。操作人员对三者之间的字符集转换过程不了解，而冒然使用EXP/IMP命令，往往在迁移过程中报错终止，或是在没有报错的情况下成功导入，但其背后却存在隐患，在查询时经常显示乱码。

2.解决方法

2.1 源端数据库（1）→EXP客户端（2）→IMP客户端（3）→目标数据库（4），数据在迁移过程中要经历如上的4个点，数据在流动过程中（如上的3个箭头）需要依次比较箭头两端的字符集，如果相同则不转换，如果不同则进行转换。如果相邻的两个点之间设置的字符集均不相同，则需要转换3次。

根据上述理论分析，最好的设置方式是，因为（1）（4）数据库的字符集是固定的，则设置客户端的字符集（2）（3）均与（1）相同，这样最多只在(3)→（4）的过程中发生一次字符集的转换。但是前提是（4）的字符集必须是（1）的的字符集的超集。客户端字符集是通过环境变量NLS_LANG来设置。

?

Linux: export NLS_LANG=SIMPLIFIEDCHINESE_CHINA.ZHS16GBK

Windows: set NLS_LANG=SIMPLIFIEDCHINESE_CHINA.ZHS16GBK

EXP导出的文件，可以通过WINDOWS上的工具UE来查看，其中第一行的第2,3个字节显示的数字代表了文件的字符集。在sqlplus里通过select nls_charset_name() from dual;可以查看该数字代表的字符集。

03 03 54 45 58 50 4F 52 54 3A

其中，03 54是16进制的数字，代表了一种字符集。将其转换为10进制为：

?

SQL> select to_number('0354','xxxx') from dual;

TO_NUMBER('0354','XXXX')

------------------------

                     852

查询852代表的字符集

SQL> select nls_charset_name(852) from dual;

NLS_CHAR

--------

ZHS16GBK

当然还可以逆向操作

SQL> select nls_charset_id('ZHS16GBK') from dual;

NLS_CHARSET_ID('ZHS16GBK')

--------------------------

                       852

2.2 ORACLE在10g以后的版本中提供了新的迁移工具EXPDP/IMPDP，此工具无需设置客户端字符集，而是由ORACLE自动去识别并完全字符集的转换。这是因为EXPDP/IMPDP并不是完整意义上的客户端，它和EXP/IMP/sqlplus并不完全一样。它只是向oracle传输了一个命令，oracle在内部生成一个任务，文件只能导出在服务器上，而不能像exp/imp一样将文件导出到远程端。但前提依然是，目标数据库的字符集应是源数据库字符集的超集。

其实，在使用exp/imp,expdp/impdp时，并不一定要严格要求目的数据库是源数据库的超集。问题的关键之处在于源端的字符能在目的端找到对应的字符。在不同字符集的数据库传输之前，我们最好通过oracle提供的csscan工具来检查两个字符集之间是否可以转换。

遇到的一个问题：
dmp文件第二第三个字节是03 54，说明是16GBK字符集，导入到106的数据库中，注释现显示的是乱码，106数据库的字符集是ZHS16GBK，通过命令找到：
select * from v$nls_parameters where parameter='NLS_CHARACTERSET';

乱码的原因是目标客户端的NLS_LANG参数不对，设置为export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK，然后再重新导入dmp文件，乱码就解决了

北京那边的导出的DMP文件是03 69，说明是UTF8字符集，现在的办法是在服务端执行export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK这个命令，重新导出文件，然后再106上重新导入