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

主题

本文探讨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及数据，费时费力易出错，及时跟后端支持沟通寻求迁移工具方为良策。

更多信息内容请移步星瑞格官方社区，期待大家加入

Sinoregal Tech ForumAsk questions, share solutions, and get to know the Sinoregal community.https://forum.sinoregal.cn/