【问题标题】:Migrating an oracle database from a non unicode server to a unicode server将 oracle 数据库从非 unicode 服务器迁移到 unicode 服务器
【发布时间】:2014-06-22 06:26:20
【问题描述】:

我想将 oracle 数据库从非 unicode 服务器(EL8ISO8859P7 字符集和 AL16UTF16 NCHAR 字符集)移动到 unicode 服务器。专门针对具有 AL32UTF8 字符集的 Oracle Express 服务器。

仅导出 (exp) 和导入 (imp) 数据失败。我们有很多 varchar2 列,它们的长度以字节为单位。当它们的内容以 unicode 映射时,它们会占用更多字节并被截断。

我尝试了以下方法:
- 使用脚本将原始数据库的所有 varchar2 列的长度加倍(varchar2(10) 变为 varchar2(20))
- 出口
- 导入新服务器

它奏效了。显然加倍是任意的,我可能应该使用 CHAR 语义将它们更改为相同的大小。

我还尝试了以下方法:
- 将所有 varchar2 列更改为 nvarchar2(大小相同 - varchar(10) 变为 nvarchar(10))
- 出口
- 导入新服务器

它也有效。

不知何故后者(转换为 nvarchar)似乎“更干净”。然后你又拥有一个 unicode 数据类型的 unicode 数据库,这看起来很奇怪。

所以问题是:有没有建议的方法在两台服务器之间移动数据库?我上面提到的两种方法中的任何一种都存在严重问题吗?

【问题讨论】:

    标签: oracle unicode


    【解决方案1】:

    迁移到 unicode 数据库需要 4 个步骤。

    1. 使用 exp[dp] 导出数据并为表生成 ddl。
    2. 更改 ddl 以将字节长度 varchar2 字段更改为字符长度字段。
    3. 使用修改后的 ddl 脚本创建表。
    4. 使用 imp[dp] 导入数据

    跳过第 2 步和第 3 步后,您会再次得到定义的字节长度字段,并且在导入期间可能会出现很多错误,因为数据不适合定义的列。如果源数据库中只有 us 字符,这不会是一个大问题,但例如拉丁字符会出现问题,因为单个字符可能需要更多字节。

    遵循所列程序可防止出现长度问题。显然有更多的方法可以做到这一点,但规则是首先让 ddl 定义正常,然后再插入数据。

    【讨论】:

      【解决方案2】:

      不要使用NVARCHAR2 数据类型,除非那是您唯一的选择。国家字符集的存在是为了处理您有一个不支持 Unicode 的现有遗留应用程序并且您希望在不触及那些遗留应用程序的情况下向支持 Unicode 的系统添加少量列的情况。使用NVARCHAR2 列非常适合这些情况,但它会在应用程序开发中产生各种问题。许多工具、API 和应用程序要么不支持NVARCHAR2 列,要么需要额外的配置才能这样做。由于NVARCHAR2 列在Oracle 世界中相对不常见,因此很容易花费大量时间来尝试解决您遇到的特定问题。不太重要的是,由于AL16UTF16 每个字符至少需要 2 个字节,因此您可能需要更多的空间,因为您的大部分数据可能包含英文字符。

      我强烈希望迁移到具有字符长度语义的新数据库(即 VARCHAR2(10 BYTE) 变为 VARCHAR2(10 CHAR))。这样可以避免将允许的长度加倍。它还可以更容易地向用户解释长度限制是什么(或在前端对这些验证进行编码)。解释一个特定的列有时可以容纳 20 个字符(仅使用英文字符时),有时可以容纳 10 个字符(仅使用非英文字符时),有时可以在中间容纳一些东西,这让大多数用户感到非常困惑(当有混合字符时)。字符长度语义使所有这些问题变得更加容易。

      【讨论】:

      • 在 UTF-8(即 Oracle 中的 AL32UTF8)中,单个字符最多可以存储 4 个字节。一个“非外来”字符是使用 UTF-8 中的 3 个字节的欧元 (€) 符号。
      猜你喜欢
      • 2015-12-23
      • 1970-01-01
      • 2023-03-29
      • 2018-04-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多