我们正在将一些数据从sql server迁移到oracle.对于在sql服务器中定义为NVARCHAR的列,我们开始在Oracle中创建NVARCHAR列,认为它们是类似的.但是它们看起来不一样.
我已经阅读了几个stackoverflow上的帖子,并想确认我的发现.
如果数据库字符集是AL32UTF8(对我们的情况是正确的),Oracle VARCHAR2已经支持unicode.
sqlServer VARCHAR不支持unicode. sqlServer显式要求列位于NCHAR / NVARCHAR类型以将数据存储在unicode中(特别是2字节的UCS-2格式).
因此,说sql Server NVARCHAR列可以/应该作为Oracle VARCHAR2列迁移是正确的吗？
解决方法
是的,如果您的Oracle数据库是使用Unicode字符集创建的,则sql Server中的NVARCHAR应该迁移到Oracle中的VARCHAR2.在Oracle中,存在NVARCHAR数据类型,以允许应用程序在数据库字符集不支持Unicode时使用Unicode字符集存储数据.
然而,迁移中需要注意的一点是字符长度语义.在sql Server中,NVARCHAR(20)为20个字符分配空间,在UCS-2中最多需要40个字节.在Oracle中,默认情况下,VARCHAR2(20)分配20个字节的存储空间.在AL32UTF8字符集中,这可能只有6个字符的足够空间,但很可能会处理更多(AL32UTF8中的单个字符需要1到3个字节,您可能希望将Oracle类型声明为VARCHAR2(20 CHAR)这表示您要为20个字符分配空间,而不管需要多少个字节.这往往比尝试解释为什么允许大约20个字符串允许而其他10个字符串被拒绝时更容易通信.
您可以在会话级别更改默认长度语义,以便您在不指定任何长度语义的情况下创建的任何表将使用字符而不是字节语义
ALTER SESSION SET nls_length_semantics=CHAR;
这样可以避免每次定义新列时输入CHAR.也可以将系统级设置为NLS团队,但是这样做是不鼓励的 – 显然,并非Oracle提供的所有脚本都针对NLS_LENGTH_SEMANTICS已更改的数据库进行彻底测试.并且可能很少有第三方脚本.
