打破平台壁垒：从 MacOS Docker:Oracle 到 CentOS DM8 的数据“迁徙”之路

一、前言

此次目标是模拟真实的异构数据库迁移场景。考虑到平时工作中用 Mac 比较多，我决定用一个特殊的拓扑结构：源端部署在 MacOS 的 Docker 容器中（Oracle 23ai），目的端部署在传统的 CentOS 7 服务器上（DM8），并使用达梦最新的迁移工具完成数据同步。

二、环境拓扑与准备

为了还原真实业务中的“数据孤岛”打通，我构建了如下环境：

角色	操作系统	数据库版本	IP地址	备注
源数据库	MacOS (M2)	Oracle 23ai Free (Docker)	192.168.31.119	端口 1521，服务名 FREE
目的数据库	CentOS 7	DM8	远程服务器 IP	端口 5236
操作终端	MacOS	SQLark / Web DTS	本机	用于执行和验证

三、第一步：源端数据构造（模拟业务）

为了测试达梦对 Oracle 各类数据类型的兼容性，我在 Oracle 端模拟创建了包含 NUMBER、VARCHAR2、DATE 以及最容易出问题的 CLOB（大字段）类型的业务表，并插入了中文数据以验证字符集。

SQL 脚本示意：

-- 1. 创建一个包含多种数据类型的员工表
-- 这里包含了数字、字符串、日期，用来测试基础迁移
CREATE TABLE EMPLOYEES (
    EMP_ID NUMBER(10) PRIMARY KEY,
    EMP_NAME VARCHAR2(100),
    HIRE_DATE DATE,
    SALARY NUMBER(10, 2),
    DEPT_NAME VARCHAR2(50)
);

-- 2. 创建一个包含大字段（CLOB/BLOB）的表
-- 这是迁移中最容易报错的地方，博客里写出来非常加分
CREATE TABLE COMPANY_DOCS (
    DOC_ID NUMBER(10),
    DOC_TITLE VARCHAR2(100),
    DOC_CONTENT CLOB,  -- 大文本对象
    CREATE_TIME TIMESTAMP
);

-- 3. 插入模拟数据（包含中文，测试字符集）
-- 插入员工数据
BEGIN
    FOR i IN 1..100 LOOP
        INSERT INTO EMPLOYEES VALUES (
            i, 
            '员工_' || i, 
            SYSDATE - i, 
            5000 + (i * 10), 
            CASE MOD(i, 3) 
                WHEN 0 THEN '研发部' 
                WHEN 1 THEN '市场部' 
                ELSE '售后服务部' 
            END
        );
    END LOOP;
    COMMIT;
END;
/

-- 4. 插入大字段数据
INSERT INTO COMPANY_DOCS VALUES (
    1, 
    '达梦迁移测试指南', 
    '这是一段非常长的文本，用来测试 Oracle 到 DM 的 CLOB 字段迁移是否正常。如果达梦端能完整显示这段中文，说明字符集配置正确。', 
    SYSTIMESTAMP
);
COMMIT;

-- 5. 验证数据条数
SELECT COUNT(*) FROM EMPLOYEES;

四、第二步：迁移前的关键检查

参考达梦生态社区文档《Oracle 移植到 DM》，在开始迁移前，必须确保目的端 DM8 的兼容性参数设置正确。

我在达梦端执行了以下检查：

SELECT para_name, para_value FROM v$dm_ini WHERE para_name = 'COMPATIBLE_MODE';

发现目标数据库的 COMPATIBLE_MODE 值为 0（达梦标准模式）。如果直接迁移，Oracle 的某些特有语法或数据类型可能会报错。

解决方法：
达梦的 COMPATIBLE_MODE 是静态参数，无法动态修改。我使用系统函数 SP_SET_PARA_VALUE(2, 'COMPATIBLE_MODE', 2) 将修改写入 dm.ini 配置文件，并在 CentOS 后台重启了数据库服务 (systemctl restart DmServiceDMTEST)。重启后再次校验，参数值变更为 2，环境准备就绪。

确保该值为 2（部分兼容 Oracle 模式），这是迁移成功的基石。

五、第三步：迁移评估与执行（核心过程）

本次我使用了达梦的SQLark 百灵连接工具对源库进行了“体检”。

连接源数据库

在初次尝试连接时，DTS 报错 ORA-12514（监听程序无法识别服务）。为了搞清楚这个 Docker 镜像默认的服务名到底是什么，我没有盲目猜测，而是直接进入容器内部使用 SQLPlus 进行了排查。

执行 show parameter service_name 后（如图所示），我发现该版本的默认服务名并非传统的 ORCL 或 XE，而是 FREE。在连接配置中修正该项后，数据库连接顺利通过。

评估结果

评估工具自动扫描了源端的对象，并给出了兼容性报告。

执行迁移 (DTS)
配置好源端（Oracle）和目的端（DM8）后，我选择了“表”和“数据”进行迁移。在映射配置中，我注意到 DTS 智能地将 Oracle 的 CLOB 类型映射为了达梦的 CLOB，VARCHAR2 映射为 VARCHAR，无需手动干预。

在迁移前的环境检查中，工具提示 EXTENT_SIZE 和 BLANK_PAD_MODE 校验失败（如图）。
问题分析：
经过查阅《达梦数据库管理员手册》，我了解到达梦的参数分为两类：
动态/静态参数（dm.ini）：如 COMPATIBLE_MODE，可以通过后期修改配置调整（后天努力）。
初始化参数（dminit）：如 EXTENT_SIZE（簇大小）和 CASE_SENSITIVE（大小写敏感），这些参数在数据库实例初始化时确立，一旦创建便不可更改（先天基因）。
决策过程：
由于当前的达梦环境是标准安装（默认 EXTENT_SIZE=16），与 Oracle 迁移最佳实践推荐的 32 不符。考虑到本次为试用期学习任务，数据量级较小，且无法在不重建库的情况下修改该参数，我决定忽略警告继续执行。
经验总结：在未来的生产环境部署中，必须在 dminit 初始化阶段就根据业务场景规划好页大小和簇大小，避免后续返工。

六、第四步：成果验证（SQLark 实战）

迁移显示完成后，结果是否正确必须经过校验。

1. 数据量比对

-- DM端查询
SELECT COUNT(*) FROM DM_TEST.EMPLOYEES;

结果显示 100 条，与源端一致。

2. 大字段与中文校验
最担心的乱码问题并没有出现。通过查询 COMPANY_DOCS 表，大段的中文描述在达梦中显示完美。

七、踩坑总结与心得

通过本次实战，我总结了以下几点经验，希望能为后续项目提供参考：

版本差异要注意： 在 Docker 环境下使用较新的 Oracle 镜像（如 23ai）时，务必确认 Service Name，不要想当然地使用 ORCL 或 XE，FREE 才是正解。
网络连通性： 本机（Mac）作为跳板机，同时连接本地 Docker 和远程服务器，需要确保 Docker 端口映射（-p 1521:1521）配置正确。
工具生态： 达梦现在的迁移工具越来越可视化、智能化，结合生态社区的文档指引，即使是新员工也能快速上手复杂的异构迁移工作。