我们正在将一些数据从 sql server 迁移到 oracle。NVARCHAR对于在 SQL Server 中定义的列，我们开始NVARCHAR在 Oracle 中创建列，认为它们是相似的..但看起来它们不是。
我已经阅读了几篇关于 stackoverflow 的帖子，并想确认我的发现。
如果数据库字符集是 AL32UTF8（在我们的例子中是这样），Oracle VARCHAR2 已经支持 unicode。
SQLServerVARCHAR 不支持 unicode。SQLServer 明确要求列NCHAR/NVARCHAR类型为以 unicode 存储数据（特别是 2 字节 UCS-2 格式）。
因此，说 SQL Server NVARCHAR 列可以/应该迁移为 Oracle VARCHAR2 列是否正确？
是的，如果您的 Oracle 数据库是使用 Unicode 字符集创建的，NVARCHAR则应将 SQL Server 中的 a 迁移到VARCHAR2Oracle 中。在 Oracle 中，NVARCHAR存在数据类型以允许应用程序在数据库字符集不支持 Unicode 时使用 Unicode 字符集存储数据。
然而，在迁移过程中需要注意的一件事是字符长度语义。在 SQL Server 中，aNVARCHAR(20)为 20 个字符分配空间，这在 UCS-2 中最多需要 40 个字节。在 Oracle 中，默认情况下，aVARCHAR2(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已更改的数据库进行了彻底的测试。而且可能很少有第三方脚本。