我们正在将一些数据从sql server迁移到oracle。对于定义为的列NVARCHAR在 SQL Server 中我们开始创建NVARCHAROracle 中的列认为它们相似..但看起来它们并非如此。
我读过 stackoverflow 上的几篇文章，想证实我的发现。
如果数据库字符集是 AL32UTF8（对于我们的情况来说就是这样），Oracle VARCHAR2 已经支持 unicode。
SQL服务器VARCHAR does not支持unicode。 SQLServer 明确要求列位于NCHAR/NVARCHAR以 unicode 存储数据的类型（特别是 2 字节 UCS-2 格式）。
因此，说 SQL Server NVARCHAR 列可以/应该迁移为 Oracle VARCHAR2 列是否正确？
是的，如果您的 Oracle 数据库是使用 Unicode 字符集创建的，NVARCHARSQL Server 中的数据应该迁移到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已经变了。可能很少有第三方脚本是这样的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
