Oracle到DM数据库迁移报告

介绍

本文档详细记录了为本次 Oracle 到 Dameng（达梦）数据库迁移项目所准备的源端 Oracle 数据库环境。

内容涵盖了虚拟机与 Oracle 数据库的规格、作为迁移源的 HR 示例方案的选型理由、安装部署过程，以及最终的环境验证结果，旨在为后续的数据迁移工作提供一个标准、可靠且可复现的入门案例。

同时，本文档还将特别记录和分析在迁移过程中遇到的一个关键现象：DTS“迁移评估”报告中的“SQL”类型不兼容问题（如 NO_CROSS_CONTAINER("SYS"."INT$DBA_SYNONYMS") 等内部查询报错），与实际“创建迁移” 100% 成功的差异性。

这一发现对于正确解读DTS评估报告、避免不必要的迁移阻碍具有一定的实践意义。

目录：

1.Oracle 环境准备

• 1.1 操作系统&部署方式
• 1.2 关键管理命令

2.迁移源Schema选型

• 2.1 方案选型
• 2.2 选型理由
• 2.3 HR 方案概览
• 2.4具体准备操作
  • 2.4.1初始连接测试
  • 2.4.2 HR 方案安装部署

3.使用DTS工具：

• 3.1迁移准备
• 3.2迁移评估
• 3.3评估兼容问题分析：
  • 3.3.1. 测试现象
    • 3.3.1.1 不同驱动的迁移评估
    • 3.3.1.2 实际迁移
  • 3.3.2. 迁移后验证
  • 3.3.3 问题分析：SQL评估失败
  • 3.3.4. 最终结论
• 3.4执行DTS数据迁移
• 3.5迁移后验证

1.Oracle 环境准备

1.1 操作系统&部署方式

本次迁移的源端 Oracle 数据库部署于独立的虚拟化环境中，具体规格如下表所示：

项目	规格/版本	备注
操作系统	CentOS 7	64位
虚拟机配置	4 处理器, 8 GB 内存, 40 GB 磁盘
部署方式	Docker 容器化部署	采用 gvenzl/oracle-xe 镜像
Oracle 版本	Oracle Database 21c Express Edition
SYSDBA 密码	Oracle123	在容器启动时通过环境变量设置

1.2 关键管理命令

• Docker 容器启动命令:

  docker run -d --name oracle-db -p 1521:1521 -e ORACLE_PASSWORD=Oracle123 gvenzl/oracle-xe
  

• 进入 Docker 容器命令:

  docker exec -it oracle-db /bin/bash
  

• 关键数据库操作命令:

  • 登录 SYSDBA: sqlplus / as sysdba
    (作用: 使用操作系统认证，以最高管理员权限登录数据库实例，无需密码。)
  • 切换到 PDB: ALTER SESSION SET CONTAINER = XEPDB1;
    (作用: 将管理会话切换到存放用户方案的可插拔数据库 XEPDB1 中。)

2.迁移源Schema选型

2.1 方案选型

本次迁移选择 Oracle 官方的 HR (Human Resources) 示例方案 作为数据源。

2.2 选型理由

选择 HR 方案作为迁移源，主要基于以下考虑：

1. 对象类型全面：HR 方案不仅包含表和数据，还涵盖了视图、索引、序列和存储过程等多种数据库对象。这能全面检验迁移工具（DTS）对不同类型对象的兼容性和转换能力，更贴近真实生产环境的复杂性。
2. 结构经典：其表间关系设计良好，包含了主外键、自关联等经典设计，能有效测试迁移后数据关系的完整性。
3. 行业标准：HR 方案是业界公认的 Oracle 学习和测试基准，使用它能确保迁移过程具有代表性和参考价值。

2.3 HR 方案概览

HR 方案模拟了一个小型企业的人力资源管理系统，核心表包括员工 (employees)、部门 (departments)、职位 (jobs)、地址 (locations) 等。

• 对象与数据量统计:

2.4具体准备操作

2.4.1初始连接测试

在进行方案部署前，首先使用 DataGrip 工具对 Oracle 实例进行连接性测试，以验证网络和基础配置的正确性。

• 连接参数:

  • 主机 (Host): 192.168.79.136
  • 端口 (Port): 1521
  • 连接方式: 服务名 (Service Name)
  • 服务名: XEPDB1
  • 用户名: sys
  • 密码: Oracle123
  • 角色 (Role): SYSDBA (注：连接sys用户必须指定SYSDBA角色)

• 连接配置:

  测试结果显示连接成功，表明数据库实例已准备就绪。

2.4.2 HR 方案安装部署

经检查，gvenzl/oracle-xe 镜像为精简版，未包含 HR 示例方案，需手动安装。

• 1. 获取脚本:
  访问 Oracle 官方 GitHub 代码库 github.com/oracle/db-sample-schemas，下载 ZIP 包并解压，获取 human_resources 文件夹。

• 2. 上传与挂载:
  将 human_resources 文件夹上传至宿主机 /home/dmdba/oracle/ 目录，并使用以下命令将其复制到 Docker 容器的 /tmp/ 目录下：

  docker cp /home/dmdba/oracle/human_resources oracle-db:/tmp/
  

• 3. 执行安装:
  进入容器，以 SYSDBA 身份登录并切换至 XEPDB1 PDB 后，执行主安装脚本。

  -- (若存在) 先删除可能冲突的旧用户
  DROP USER hr CASCADE;
  
  -- 执行主安装脚本
  @/tmp/human_resources/hr_install.sql
  

  在脚本执行过程中，根据提示输入密码 hr、表空间 users 等参数。

• 4. 脚本自动校验:
  安装脚本执行完毕后，会自动进行数据校验，输出结果显示所有表的预期行数与实际行数完全一致，证明数据已完整加载。

• 5. 外部工具验证:
  使用 DataGrip 工具连接 hr 用户，成功查看到 HR 方案下的所有数据库对象，包括表、视图、序列等，与预期完全相符。

结论：至此，源端 Oracle 数据库及 HR 示例方案已全部准备就绪，环境稳定可靠，数据完整，可以作为本次迁移工作的正式数据源。

3.使用DTS工具：

3.1迁移准备

1. 创建目标库用户和表空间：

   • 登录目标DM数据库（以SYSDBA身份）。

   • 根据迁移准备文档的要求，为即将迁入的HR方案创建对应的用户（例如，也叫HR）和表空间 。

   • 示例SQL (在DM中执行):

     -- 假设为HR创建表空间，根据实际情况调整大小
     CREATE TABLESPACE "HR_DATA" DATAFILE 'HR_DATA.DBF' SIZE 128;
     -- 创建用户并指定默认表空间
     CREATE USER "HR" IDENTIFIED BY "hr" DEFAULT TABLESPACE "HR_DATA";
     -- 授予用户必要的权限
     GRANT "DBA" TO "HR"; 
     

2. 调整目标库参数（重要）：

   • 为了最大限度兼容Oracle，建议检查并调整DM数据库的COMPATIBLE_MODE参数。

   • 示例SQL (在DM中执行):

     -- 切换到 Oracle 兼容模式
     SP_SET_PARA_VALUE(1, 'COMPATIBLE_MODE', 2);
     -- 注意：该参数修改后需要重启数据库实例才能生效。
     

   • Oracle默认对象名大写，DM默认大小写敏感，迁移Oracle保持默认即可。

3.2迁移评估

1. 启动DTS工具：

   • 在Windows环境下启动DM数据迁移工具 。

2. 新建评估工程：

   • 新建一个工程，例如“Oracle_HR_Migration” 。

   • 在工程下，右键选择【新建评估】 。

   • 选择评估方式：Oracle ==> DM 。

3. 配置评估源：

   • 数据源：
     • 主机名: 192.168.79.136
     • 端口: 1521
     • 服务名: XEPDB1
     • 用户名: SYSTEM
     • 口令: Oracle123
     • 角色: <默认>
     • **数据库版本：**Oracle 21c

4. 对象详情总览：

5. 分析评估报告：

   • DTS会扫描你选择的模式，并生成一份“兼容性报告” 。
   • 重点关注：“不兼容”的对象 。
   • 处理不兼容：DTS工具允许你当场修改SQL 。例如，Oracle特有的EDITIONABLE关键字 在DM中不兼容，你需要手动删除该关键字，然后点击【校验】 ，直到DTS提示“兼容” 。

6. 评估报告具体内容如下：

   • 对象统计：
   • 兼容性分析：
     

3.3评估兼容问题分析：

3.3.1. 测试现象

3.3.1.1 不同驱动的迁移评估

在所有测试中，HR模式的对象（表、视图、序列、存储过程等）均评估为“转换兼容”或“完全兼容”。唯一的“不兼容”项均来自“SQL”类型。

为检查问题原因，个人更换了不同版本的驱动，其他不变，检查评估结果是否改变，结果如下：

• Oracle 21c (默认驱动)：

  • SQL总数：51条
  • 不兼容SQL：6条
    

• Oracle 23c：

  • SQL总数：324条
  • 不兼容SQL：63条（全部为SQL类型）

• Oracle 12c：

  • SQL总数：与21c/23c均不同
  • 不兼容SQL：存在（全部为SQL类型）

3.3.1.2 实际迁移

• 测试场景：分别对 21c 和 12c（兼容度最低）进行了迁移。
• 迁移结果：均为100% 成功，DTS工具未报告任何错误。

3.3.2. 迁移后验证

迁移成功后，对目标DM库中的HR模式进行了完整性验证：

1. 对象数量验证：
   • 命令：select object_type, count(*) from all_objects where owner = 'HR' group by object_type order by 1;
   • 结果：正确。DM库中的对象类型与数量，除索引数量外，与源端Oracle完全一致。
   • Oracle：
   • DM：
   • 索引差异分析：我们发现DM端的索引数量可能多于Oracle端。分析认为：
     • 主键/唯一约束会自动创建索引。
     • DM为了优化性能，可能自动为Oracle中默认没有索引的外键（Foreign Key）创建了索引。
2. 数据行数验证：
   • 命令：SELECT 'EMPLOYEES', COUNT(*) FROM HR.EMPLOYEES UNION ALL ... (已省略)
   • 结果：正确。所有表的行数均与源端Oracle一致。

3.3.3 问题分析：SQL评估失败

评估报告中“SQL”类型的不兼容，主要源于两种SQL：

1. 来源A：DTS从V$SQL抓取的“样本”
   • 现象：DTS评估报告中的“SQL”总数，会随着驱动版本、虚拟机重启、重复评估而动态变化（50条 -> 200多条）。
   • 原因：这证明了DTS评估时，会从Oracle的V$SQL（动态性能视图）中抓取近期执行过的SQL作为“样本”。V$SQL是动态变化的，因此DTS每次抓取的样本集都可能不同。
   • 不兼容示例：
     • 例1：select value(p$) from "XDB"."XDB$ALL_MODEL" as of snapshot(:2)...。
     • 例2：SELECT /*+ NO_STATEMENT_QUEUING RESULT_CACHE (SYSOBJ=TRUE) OPT_PARAM('_ENABLE_VIEW_PDB', 'FALSE') */ "OWNER","OWNERID","TABLE_NAME","OBJECT_ID","OBJECT_TYPE#","COLUMN_NAME","COMMENTS" FROM NO_CROSS_CONTAINER("SYS"."INT$DBA_COL_COMMENTS") "INT$DBA_COL_COMMENTS" WHERE "INT$DBA_COL_COMMENTS".SHARING=0 AND ("INT$DBA_COL_COMMENTS"."COMMENTS" IS NOT NULL AND "INT$DBA_COL_COMMENTS"."OWNER"=:1 AND ("INT$DBA_COL_COMMENTS"."TABLE_NAME"=:2 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:3 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:4 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:5 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:6 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:7 OR "INT$DBA_COL_COMMENTS"."TABLE_NAME"=:8))
2. 来源B：DTS评估模块的内部查询
   • 现象：DTS评估时，稳定出现几条针对NO_CROSS_CONTAINER、INT$DBA...的查询失败。
   • 不兼容示例：
     • SELECT count(*) FROM NO_CROSS_CONTAINER("SYS"."_INT$_ALL_SYNONYMS_FOR_AO") "_INT$_ALL_SYNONYMS_FOR_AO" WHERE 1=1 AND 1=1
   • 分析：这不是V$SQL的样本，可能是DTS的“迁移评估”模块（可能受旧驱动影响）自己生成的、用于查询Oracle 21c/23c多租户架构数据字典的内部SQL。这些SQL本身带有Oracle独家语法或内部视图，导致DTS评估器评估失败了。

3.3.4. 最终结论

DTS工具的“迁移评估” 与“创建迁移” 是两个在功能上相对独立的模块。

“迁移评估”中的SQL”类型评估项，其结果不具备决定性。该项评估失败（指不兼容的对象为SQL对象，若为模式对象需要手动修改兼容），不代表实际的“创建迁移”会失败。

在本次（Oracle HR）迁移测试中，所有版本的Oracle（12c, 21c, 23c）评估均显示大量“SQL”类型不兼容，但实际迁移 100% 成功，且数据与对象完整性校验通过。

总结：

• “SQL”对象评估类别仅作参考，大部分是Oracle内部SQL，不代表业务应用SQL不兼容。相同的业务应用SQL在不同的数据库中会有不同的执行计划和中间过程。
• 若要在DTS评估阶段考量业务应用SQL兼容性，建议将评估选项中的SQL采集方式改为从文件中抽取

3.4执行DTS数据迁移

在评估完成并处理完不兼容项后，才开始正式迁移。迁移过程和结果及检测参阅上面3.3 使用DTS工具：评估兼容问题分析

1. 新建迁移任务：

   • 在工程下，右键选择【新建迁移】 。
   • 选择迁移方式：Oracle ==> DM 。

2. 配置源和目的：

   • 源 (Oracle): 再次输入Oracle连接信息 。
   • 目的 (DM): 192.168.79.136:5236

3. 配置迁移选项（导师划重点）：

   • 保持对象名大小写 ：Oracle默认大写，勾选此项能确保对象名在DM中也保持大写，避免应用SQL找不到对象 。
   • 使用默认数据类型映射关系 ：先勾选。HR方案中的VARCHAR2和DATE是经典难题 。如果评估阶段没有发现问题，可使用默认映射。
   • 字符集问题：确保源库和目标库字符集一致。本案例Oracle版本默认使用的字符集为：AL32UTF8，因此迁移策略中选择对应的字符集。
     • 关于Oracle字符集查询：select * from V_$NLS_PARAMETERS where parameter='NLS_CHARACTERSET';

4. 选择与映射：

   • 选择对象：选择HR模式下的所有对象（表、视图、序列、存储过程等） 。
   • 设置映射：确保源模式HR正确映射到目标模式HR 。

5. 审阅并执行：

   • DTS会列出所有任务 。确认无误后，点击【完成】开始 。

3.5迁移后验证

具体操作和结果参阅上面3.3使用DTS工具：评估兼容问题分析

1. 对比对象数量：

   • 在目标DM数据库中，使用HR用户登录。

   • 执行SQL，对比HR方案中的对象类型和数量 。

   • 示例SQL (在DM中执行):

     select object_type, count(*) 
     from all_objects 
     where owner = 'HR' 
     group by object_type;
     

   • 将这个结果与你在源端Oracle（或迁移报告）中的统计进行对比。

2. 抽查数据完整性：

   • 对比核心表（如 EMPLOYEES, DEPARTMENTS）的行数 。
   • 抽查几条具体数据，确认中文字符（如果有）或特殊数据显示正常。

3. 合理差异：

   • 约束类对象（如主键、外键）的名称可能与源库不同，因为它们是系统自动命名的 。
   • 验证关键点：只要约束的数量一致，且功能（例如主外键关系）正确，那么这种命名差异是正常的