简介这是一份面向达梦数据库运维与实施人员的PPT资料聚焦从 Oracle、MySQL、MariaDB 等数据库向达梦迁移的完整流程与实操要点。内容按“引言—迁移准备—正式迁移—总结”展开重点讲清迁移前的调研项、网络与客户端环境判断、DTS/DMHS 工具选型以及初始化参数、表空间、用户权限等关键配置针对迁移中常见的 DDL 解析失败、表迁移成视图等问题给出了驱动版本、中间库中转、更换工具版本等排错思路适合正在做信创项目或数据库迁移的初中级工程师参考。资源包为 1 个 PPTX 文件大小 5.83MB图文结合便于按章节快速查阅目前已有 210 人学习属于小而精的实操型讲解材料看完后能对达梦数据迁移的前期评估、工具选择和故障应对建立较完整认识。1. 达梦数据库数据迁移先想清楚“迁什么、怎么迁”再动手接手一套要从 Oracle 换到达梦数据库的存量业务第一个被问的问题往往不是“要不要迁”而是“怎么迁最快、丢不丢数”。达梦数据库数据迁移这件事工具选型比执行更决定成败同样是迁到达梦源端是 Oracle、MySQL 还是另一套 DM数据量是几十 GB 还是几百 GB停机窗口给不给方案可能完全不同。我用得最多的三条路线是官方 DM 数据迁移工具DTS、命令行 dexp/dimp 和纯 SQL 脚本导入它们分别对应图形化库迁移、文件级迁移和结构级迁移。这篇笔记把这几条路线的选型边界、执行步骤和踩坑点一次讲透适合正在做国产化库替换或达梦库间搬迁的 DBA 与后端开发。2. 迁移方式选型四种路线的适用边界与取舍2.1 先把迁移对象拆开结构、数据、状态三件事迁库不是把表数据拷过去就完最常见的翻车点在于只迁了表和行数据漏了序列、视图、存储过程、触发器和权限。我一般把迁移对象拆成三层第一层是结构包括建表语句、索引、约束、视图、存储过程和触发器第二层是数据包括业务行、大字段和序列当前值第三层是状态包括自增起点、权限、统计信息和用户配额。DTS 这类图形化工具会按模块呈现对象清单但默认选择经常不全。比如某些版本只勾了“表和数据”时序列可能不在迁移列表里等应用一插入数据就报主键冲突。所以动手前先列一份源端对象清单有哪些模式、每个模式下有多少张表、哪些表含 CLOB/BLOB、哪些表有自增列、是否需要迁移存储过程。这份清单决定了后续工具参数怎么调也决定了迁移完成后的核对范围。2.2 四种常见路线对比与选型判断我遇到的项目里迁移到达梦的路线基本是下面四种没有一种能覆盖所有场景选错路线的代价通常比执行中的问题更大。迁移路线适合数据规模停机要求技术门槛典型场景DTS 图形化迁移几十 GB 以内可停数小时低Oracle/MySQL 异构库到 DM 的全量迁移dexp/dimp 命令行几十 GB 到上百 GB可停数小时中DM 到 DM 的库间搬迁、异地归档SQL 脚本导入导出码表、配置表量级随时可执行低只用导几张表、迁移结构定义业务双写/ETL 同步不限几乎不停机高大库在线迁移、长期并行切换先看源端类型和数据量。Oracle 迁达梦首选 DTS因为 DTS 内置了 Oracle 到 DM 的常用类型映射和语法转换存储过程、包这类 PL/SQL 对象也能批量转换。MySQL 迁达梦同样走 DTS但要注意 MySQL 的 tinyint(1)、datetime 精度这类细节。DM 迁 DM 且数据量上百 GB 时我倾向于 dexp/dimp 文件级迁移导出物理解析比图形化工具逐表读取更稳还能压缩配合 scp 传输比长连接 JDBC 更可控。再看停机窗口。能停几个小时一次性全量迁移就够了业务不能停就得先做一次全量 DTS再补增量数据或用中间件持续同步。SQL 脚本适合小对象迁移。用 Navicat 这类管理工具连到达梦执行 .sql 时注意连接字符集要和库一致否则导入的中文会直接乱掉整库数据量一大SQL 文本方式会非常慢而且特殊字符、换行符都可能让脚本在中间断开。选型判断我一般就三句话异构小库用 DTS 一次全量同构大库用 dexp/dimp 文件级分批只能停十分钟的库先 DTS 全量再预留停机窗口补一段增量 SQL。业务双写和 ETL 同步是最后考虑的重型方案没有专职运维团队别轻易上。3. 用 DM 数据迁移工具跑通全库迁移建工程到执行的完整步骤3.1 迁移前检查实例参数、用户规划与源端只读确认目标实例如果是 Linux 上的 DM8先把数据库装好、实例初始化并启动服务再用 DTS 去连。有两个初始化参数迁移前必须确认字符集和页大小。达梦的页大小在初始化实例时定死之后改不了页大小直接影响 varchar 列能存的最大长度字符集同理GBK 库和 UNICODE 库对同一串中文的字节数算法不同源端 GBK 下刚好能塞下的值迁到 UTF-8 目标端可能直接报超长。另外确认目标库授权是正式 key 还是试用 key剩余有效期够不够撑过整个迁移周期别迁到一半实例报 license 失效这种事真发生过。用户规划上达梦的“用户”和“模式”是一一对应的迁移前先按业务建好目标用户分好表空间配额。很多项目图省事直接用 SYSDBA 导入后面应用连库时模式和权限全对不上反而多花一倍时间返工。我通常建和源端同名的用户源端 schema 是 APP目标端就建 APP 用户配额给足这样 DTS 映射的时候几乎不用改。源端只读这块DTS 迁移过程中源库不需要完全只读但结构迁移阶段尽量错开业务高峰。迁移前在源端跑一次对象统计生成基线清单方便迁移后和 DTS 的选中清单比对-- 源端统计每个模式下对象数量用于核对DTS迁移清单 SELECT owner, object_type, COUNT(*) AS obj_cnt FROM all_objects WHERE owner NOT IN (SYS,SYSTEM,OUTLN,XDB,MDSYS,DBSNMP) GROUP BY owner, object_type ORDER BY owner, object_type;这段 SQL 在 Oracle 源端直接跑达梦源端也能用因为达梦兼容 Oracle 的 all_objects 视图。跑出来的结果里owner 是业务模式的才需要迁系统模式不用管。DTS 里选对象时拿这份清单对照勾选能有效防止漏掉某个模式下的存储过程或序列。3.2 DTS 建工程与配置源连接、目标连接、对象映射DM 数据迁移工具DTS随达梦安装包一起提供Windows 环境下从菜单启动Linux 环境下执行 dts 脚本启动。首次使用按下面几步走新建工程工程名按迁移任务起比如 oracle_to_dm_app。右键新建迁移选择迁移方式。不同版本叫法略有差异有的是“库迁移”有的是“对象迁移”本质都是先连源、再连目标、最后选对象。配置源连接。数据库类型选 Oracle填写 IP、端口、服务名或 SID。Oracle 建议用 JDBC 直连方式省得在 Windows 上配 ODBC 驱动和版本匹配问题。配置目标连接。数据库类型选 DM填写目标实例 IP、端口 5236、用户名和口令。测试连接成功后进入对象选择页面按模式勾选表和其它对象类型。进入映射关系页面默认同名映射。异构迁移时逐项检查类型转换MySQL 的 tinyint(1) 到达梦后是否还是期望的语义Oracle 的 number(1,0) 是否被转成了达梦的 numeric 精度这些在预检阶段会显示警告不要直接忽略。点击预检查看类型转换和语法兼容报告。预检里的警告分类看红色一般会阻断执行黄色可以迁但要注意边界。对象选择页面是漏项高发区。我一般把“视图、存储过程、序列、触发器”这些对象类型全部展开对照 3.1 节的 SQL 统计结果逐个核对。特别是序列如果源端有自增列序列漏迁了应用插入数据立刻撞主键。3.3 执行与监控线程数、批量提交与产物日志执行阶段真正需要调的就两个参数线程数和批量提交行数。线程数控制并行读取和写入的并发度默认 4内网环境且目标端磁盘不差时调大到 8 或 16 能明显提速跨公网迁移时反而调小避免丢包重传拖垮整体进度。批量提交行数控制每个事务写入的行数默认值通常在 500 到 1000批量太小事务太多跑得慢批量太大会放大锁竞争和回滚段压力。含 CLOB/BLOB 的大字段表不要和普通大表混在同一个任务里。我做迁移的习惯是先把所有普通表跑完再单独建一个迁移任务只迁大字段表批量提交行数调小到 200 左右。大字段迁移时内存缓冲占用高混在一起容易让某个超大 LOB 列卡住整个任务单独跑还能精确定位是哪张表的问题。迁移过程中DTS 界面会打印当前进度和失败的 SQL。执行结束后不要只看“完成”两个字重点看错误日志里的失败记录数。只有几条失败时记录里能查到具体表和主键值针对性地补迁这几条失败数量大就回到映射关系里查类型兼容问题。迁移完成后立刻跑一段生成 count 语句的 SQL把目标端所有业务表行数统计一遍-- 目标端生成对APP模式下所有表执行count的SQL文本 SELECT SELECT || TABLE_NAME || AS TAB, COUNT(*) FROM APP. || TABLE_NAME || ; AS cnt_sql FROM all_tables WHERE owner APP ORDER BY TABLE_NAME;把生成出来的 SQL 逐条执行输出结果保存成文件再和源端跑同样的统计做行数 diff。这段 SQL 的核心价值是用数据库自己生成 SQL避免手写几十张表的 count 语句漏一张表就白核了。实际操作时可以在源端和目标端各跑一遍结果导出成文本后用 diff 工具比对行数不一致的表单独重查。4. 数据迁移避坑实录字符集、大字段与中断恢复的五个现场4.1 字符集不一致中文乱码与长度报错现象迁移完成后应用查出来的中文显示成问号或乱码部分表在结构迁移阶段直接报“列长度超出限制”导致建表失败。原因源端和目标端字符集不一致。Oracle 的 AL32UTF8 对应达梦的 UNICODEGBK 源端对应达梦的 GBK。如果源端是 GBK目标端初始化选了 UNICODE那么同一串中文在 UTF-8 下需要更多字节按字节定义长度的 varchar 列就会超长。另一种情况是 DTS 连接串没指定字符集参数工具按默认字符集解析数据写入目标端后自然错位。解决迁移前确认两端字符集达梦实例初始化时就把字符集定成和源端一致。已经迁乱了的话找出来乱码集中在哪几张表单独重迁这几张表不要在已经乱掉的数据上反复 UPDATE。重迁时在 DTS 连接参数里显式指定字符集Oracle JDBC 连接串加对应字符集参数达梦端连接串同样加上 characterEncoding 相关设置。吃不准就用单表单测先迁一张含中文的表验证编码再跑全量。4.2 CLOB/BLOB 大字段静默丢数现象行数统计完全一致但某张表的 CLOB 字段内容后半段被截断BLOB 文件迁移后打开损坏。原因这是最迷惑人的一种失败因为它不报错。批量提交行数过大、驱动在分块读写大字段时缓冲不足映射关系里 CLOB 被隐式转成 varchar 时自动截断都可能导致部分大字段静默丢失。行数对得上但内容不对属于迁移里的“黑匣子”问题。解决大字段表单独建任务、批量提交调小迁移后在源端和目标端分别统计大字段的总长度和空值数逐项对比-- 目标端检查大字段总量防止静默截断 SELECT COUNT(*) AS cnt, SUM(DBMS_LOB.GETLENGTH(content)) AS total_len, SUM(CASE WHEN content IS NULL THEN 1 ELSE 0 END) AS null_cnt FROM app.doc_content;源端同样跑这条 SQL对比两边 total_len 和 null_cnt。total_len 对不上就说明有大字段内容丢失把这张表整个重迁。不要尝试定位到具体哪一行大字段表通常数据量大定位成本高直接全表重迁更省钱。4.3 自增列与序列不同步应用插入冲突现象迁移后查询数据一切正常但应用一执行 INSERT 就报主键冲突或唯一约束冲突。原因DTS 迁移了表数据和序列定义但序列的当前值没有被拨到已迁数据的最大值之后。Oracle 和达梦的序列是独立对象迁移工具把序列的段信息带了过去而序列当前位置还停留在源端的旧值。比如表里已有 20 万行目标序列 NEXT 值还停在 5 万一插入就撞主键。解决迁移后手动把目标序列重置到表数据最大值之后。达梦支持 ALTER SEQUENCE ... RESTART WITH-- 目标端把序列起点拨到当前业务数据最大值之后 SELECT MAX(id) FROM app.doc_info; -- 假设返回 200000 ALTER SEQUENCE app.seq_doc_id RESTART WITH 200001;注意这里必须严格大于最大值不能等于。等于是把序列拨到了已经占用的值上下一次插入又会冲突。多张自增表就写个脚本循环处理别手工一张一张敲。这个脚本建议在迁移核对阶段就准备好等应用插入报错再处理就是被动救火了。4.4 模式名与权限错位表“不存在”的假象现象DTS 任务执行成功目标端工具里能看到表但应用连库查询时报“表或视图不存在”。原因达梦里用户和模式一一对应应用连接默认找和用户名同名的模式。源端 schema 是 APP目标端建的用户却是 APP_READONLYDTS 把表迁到了 APP 模式下而应用连接串指定的用户是 APP_READONLY自然找不到表。还有一种是目标端 APP 用户没建DTS 把表建到了 SYSDBA 模式下应用用 APP 账号登录后什么都看不到。解决目标端坚持建和源端同名的用户DTS 映射时把源模式显式映射到目标同名模式。已经迁错位置的别尝试在达梦里直接改 schema 归属常见做法是重新导出再导入把映射关系写对或者用视图/同义词兜底。返工虽然痛但数据一致性不能靠同义词硬撑。4.5 网络中断与断点续传任务白跑两小时的后悔药现象一个跑了两小时的任务进度到 87% 时网络闪断整个任务失败只能从头再来。原因DTS 长时间占用一个数据库连接网络设备空闲超时或防火墙策略把连接断了。目标端大事务回滚也需要时间任务失败后清理回滚段又花了很长时间整体白跑。解决三个手段配合使用。一是把大任务拆小按模式或按表建多个迁移任务单个任务控制在 30 分钟到 1 小时内任何单点失败损失都可控。二是预检网络迁移窗口前让运维把防火墙空闲超时调长避免长任务被中间设备断开。三是对超大表先迁结构再迁数据减少单任务的持续时间。部分版本 DTS 支持从失败点继续但我从来不会把这个能力当成计划内方案任务拆碎才是真正靠谱的断点续传。5. 迁移后核对与增量补充一个可复用的验证套路5.1 三组核对 SQL行数、主键、业务探针迁移完成后的核对我固定分三步走。第一步行数核对用 3.3 节生成的 count SQL 在源端和目标端分别跑结果做 diff。第二步主键核对抽查核心业务表是否有重复主键-- 目标端抽查核心订单表的主键重复情况 SELECT order_id, COUNT(*) FROM app.orders GROUP BY order_id HAVING COUNT(*) 1;这一步非常关键有些迁移工具在唯一索引转换出现问题时会把主键约束丢掉重复数据悄悄进去。第三步业务探针挑两三条应用里最常跑的 SQL比如“最近 7 天订单关联客户名”这种多表查询在源端和目标端各跑一遍数字能对得上才算业务层通过。只要有一组核对没过就按对应表重迁不要带着疑问切流量。5.2 停机窗口内的增量补充与统计信息刷新如果迁移窗口内业务没有完全停死做完全量迁移后还会有新写入的数据。常见做法是停机前预留一段增量补扫时间把全量之后产生的新数据导出成 SQL 或文件在停机窗口内导入目标端。我一般会把增量补扫的时间留足而不是压到最后一分钟才动手。补扫完成后在目标端收集统计信息。DTS 只搬数据不会把源端的统计信息同步过来统计信息缺失会让优化器选出很差的执行计划-- 目标端刷新整个APP模式下所有对象的统计信息 DBMS_STATS.GATHER_SCHEMA_STATS(APP);达梦兼容 Oracle 的 DBMS_STATS 包这条语句可以直接用。统计信息刷新完再跑一次业务探针 SQL确认执行计划正常然后切流量。我做迁移有个习惯不管工具界面上显示什么状态不把这三组核对跑完不签字。有一次就是行数全对、主键重复没查上线当晚业务对账翻车后来花了一整夜清理重复数据。从那以后核对脚本永远提前准备好迁移完先跑脚本再谈切换。希望帮到你。本文还有配套的精品资源点击获取
