Oracle迁移至SinoDB字符集选择及影响落地文件字符集的参数探讨

作者:zuomm

主题

本文探讨Oracle数据迁移至SinoDB数据库中字符集的选择已经中间需要落地时影响落地文件的参数。

产生背景

在项目中需要将一个Oracle中的数据迁移至SinoDB中,基础环境如下

源端:Oracle 11g ,提供连接串

客户端:windows工作机,已部署sqlplus客户端等

目标端:Sinodb 12.1FC8X03

因缺乏工具支持,在现场采用手动梳理表结构,由window主机上cmd命令下将oracle导出成落地文本后传入目标端进行导入,在涉及中文等问题时,遇到导入错误及中文乱码等问题。

知识梳理

字符集基础:

SinoDB支持的字符集从大到小依次为:

GB18030->GBK->GB2312->ASICII

UTF8为单独的编码体系,同时兼容ASICII

UTF8->ASICII

UTF8比GB18030对中文的支持更好,但是UTF8采用的3字节编码所以会更消耗空间,兼容性来讲首选UTF8

Oracle涉及参数:

NLS_CHARACTERSET 服务端字符集

NLS_LANGUAGE 服务端显示字符集

NS_LANG 客户端字符集

SinoDB涉及参数:

DB_LOCALE 数据库字符集

CLIENT_LOCALE 客户端字符集

CMD显示字符集

chcp 936 GBK2312

chcp 65001 UTF8

操作系统字符集

LANG 操作系统显示字符集

其他查询工具字符集,如xmanager等设置与客户端字符集一致即可

现场实践

客户现场参数如下:

Oracle

NLS_CHARACTERSET=AMERICAN

NLS_LANGUAGE= ZHS16GBK

NLS_TERRITORY=AMERICA

客户端字符集:

NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

导出文件后编码为ANSICII-extented格式,需手动转文本格式且转换容易失败。

经研究测试后发现NLS_LANG可以设置为其他编码格式,而且此时导出的文件会以此编码进行存储

NLS_LANG= AMERICAN_AMERICA.UTF8

导出的文件编码为UTF8

目标端:

DB_LOCALE=zh_CN.utf8

CLIENT_LOCALE=zh_CN.utf8

导入后显示正常无报错。

总结及思考

SinoDB中文的字符集最好使用UTF8,在现场GB18080依然有很多中文无法传入或者显示。

Oracle的NLS_LANG影响导出文本的编码

Windows下cmd的字符编码只影响显示不影响导出的文本

后续思考:

能否由Oracle产生ANSCII格式直接导入Sinodb en_US.819库中,JDBC连接串中进行NEWCODESET=XXX这种形式进行处理,因时间问题在客户现场未能进行研究测试,由待后续有机会进行研究测试。

对于涉及数据迁移的工作,最好不要尝试进行手动迁移schema及数据,费时费力易出错,及时跟后端支持沟通寻求迁移工具方为良策。