企业官网建设流程全解析

上周刚帮客户把一套 MySQL 生产库迁到达梦 DM8，原以为就是导个数据的事，结果光是 DTS 的启动环境、授权 key 和类型映射就折腾了小半天。事后复盘才发现，很多人第一次接触达梦数据库，拿到手根本不知道从哪下手，尤其是像 DTS 这种数据迁移工具，看着是个向导式界面，实际操作里全是细节。这篇就把达梦数据库的数据迁移工具 DTS 从头到尾聊透，包括工具从哪来、怎么启动、迁移任务怎么配置、迁移完怎么校验，以及我踩过的坑——适合正在做国产化替代、系统迁移、或者刚把达梦 DM8 装起来准备上手的朋友。

1. DTS 是达梦迁移数据的核心入口，先搞懂它能干什么

1.1 为什么数据迁移绕不开 DTS

达梦数据库 DM8 自带的管理工具不少，有数据库管理工具、性能监视工具、集群部署工具等等，但真正和“搬家”强相关的，就是 DTS。DTS 全称是 DM Data Transformation Service，官方叫达梦数据迁移工具，江湖上更多人直接叫它 DM 数据迁移工具。它解决的问题非常明确：把源库的数据和对象结构搬到达梦数据库里，并且尽量保证搬家过程中不丢数据、不错类型、不废索引。

你可能说，数据迁移不是可以导出 SQL 文件再导入吗？确实能导，但只适用于小库、简单表结构。DTS 做的事情远不止“执行 SQL”，它能识别源数据库的对象定义、自动做类型映射、保留主外键和索引、甚至能把存储过程这种复杂对象一并迁过去。重点是，DTS 支持异构数据库迁移，比如从 Oracle、MySQL、SQL Server、PostgreSQL 到达梦，也支持达梦之间同构迁移。这一点在实际项目里特别重要——国产化替换场景中，最常见的就是把 Oracle 或 MySQL 迁到达梦，光靠手写 SQL 脚本，那工作量是灾难级的。

说到底，DTS 是一个图形化的迁移工作台，通过向导方式一步步完成源库连接、目标库连接、对象选择、类型映射、数据抽取和校验。只要你愿意，它还能把迁移任务保存下来，下次直接复用。

1.2 DTS 能迁什么、不能迁什么

先列一下 DTS 支持的常见数据源，方便你对号入座：

• 达梦数据库自身（DM6、DM7、DM8）
• Oracle 数据库
• MySQL / MariaDB
• SQL Server
• PostgreSQL
• 其他支持 ODBC / JDBC 的数据库
• 文本文件、Excel 文件（特定版本）

它能迁移的对象主要包括表、视图、序列、索引、主键、外键、约束、存储过程、函数、触发器等。什么意思呢？就是说，你建在 Oracle 里的表结构、自增序列、存储过程，迁移后基本能对应到达梦的形态，而不是只把数据搬过去、表还得重新建。

但也别对它抱有不切实际的期待。DTS 不是万能的，某些源库特有的数据类型（比如 Oracle 的 XMLType、SDO_GEOMETRY 空间类型），DTS 处理起来会降级甚至报错；源库的自定义类型、包内变量等复杂 PL/SQL 对象，迁移后往往需要手工调整。还有，超大表（比如上亿行的日志表）虽然能迁，但效率需要靠分批提交、并行抽取这些参数去调，不是无脑下一步就完事。

提示：提前明确“能迁什么、不能迁什么”，比在迁移失败后到处排查更重要。做迁移前，最好先在测试库上把源库的对象清单导出来，人工扫一遍，把特殊对象标出来，再决定是用 DTS 自动迁，还是手工补脚本。

2. 环境准备：装好达梦、找到 DTS、把 key 换成正式授权

2.1 DTS 从哪来：不用单独下载，安装包自带

很多人上来就搜“kes dts 下载”“dm数据迁移工具下载”，其实方向就歪了。DTS 不需要单独下载，它是达梦数据库客户端套件的一部分。你在 Windows 上安装达梦 DM8，或者把达梦安装包在 Linux 解压安装后，DTS 就在安装目录的tool文件夹下面。

以典型安装为例：

• Windows 版安装包比如dm8_202408_x86_win_64.zip，解压后运行setup.exe安装，默认安装目录是D:\dmdbms（具体看你指定），打开D:\dmdbms\tool，里面就有dts.exe，双击就能启动。
• Linux 版安装包类似dm8_202408_x86_rh6_64.zip，解压后执行./DMInstall.bin安装，默认目录是/opt/dmdbms（或你自定义的路径），工具目录是/opt/dmdbms/tool，里面有可执行的dts脚本。

顺便说一句，达梦数据库分为客户端和服务器端组件。如果你只需要 DTS 去连远程达梦库做迁移，理论上可以只装客户端工具，但大多数情况下大家还是直接装完整版，因为迁移过程中可能还要用管理工具去检查目标库状态，装完整版省心。

安装完成后，别急着用，先确认达梦服务已经启动。Windows 下可以在服务里看DmServiceDMSERVER，Linux 下可以用systemctl status DmServiceDMSERVER查看。DTS 只是个连接客户端，目标库本身必须活着，它才能把数据写进去。

2.2 Linux 环境跑 DTS，最容易被图形界面卡住

在 Windows 上双击dts.exe很自然，但到了 Linux 服务器上，很多运维习惯用命令行，装完直接敲/opt/dmdbms/tool/dts，结果报错连图形界面都起不来。原因很简单：DTS 是图形化工具，需要图形环境支持，如果服务器是无显示器环境，默认起不来。

Linux 下有两种常见玩法：

第一种，在有图形界面的 Linux 桌面环境里，直接用终端执行/opt/dmdbms/tool/dts，前提是安装时选了图形工具组件，而且桌面环境正常。

第二种，服务器没有界面，需要通过 X11 转发或 VNC 远程桌面方式。比如你在 Windows 上装了 Xshell 或 MobaXterm，开启 X11 转发，然后在远端执行dts，界面会投射到本地。注意，没有图形环境裸跑是必然报错的，不要以为是工具坏了。

还有一部分人喜欢在 Linux 上用命令行模式做迁移，达梦确实提供过命令行版本的迁移工具，但说实话，图形化的 DTS 交互体验清晰很多，迁移前的映射检查也更方便。只要不是完全没有图形条件的极端场景，我都建议优先用图形界面的 DTS。

注意：生产服务器一般不建议直接装图形桌面。我的习惯是，在本地 Windows 装达梦管理工具，用它能远程连接和操作 Linux 上的达梦库；或者用 X11 转发跑 DTS，迁移完就关。这样既不污染服务器环境，也能正常操作图形工具。

2.3 授权文件 key 的正确换法

达梦数据库是有授权机制的，通常安装后会有一个试用期或者试用版 key。如果你遇到“连接数据库提示授权无效”“试用版限制”之类的提示，别急着怀疑 DTS 有问题，先检查达梦数据库的授权 key。

达梦的授权文件是dm.key，放在达梦安装目录下。Windows 默认可能在D:\dmdbms\dm.key，Linux 默认在/opt/dmdbms/dm.key。获取正版 key 后，替换掉旧文件，然后重启达梦服务，让新 key 生效。

具体步骤：

1. 确认当前 key 路径：用达梦管理工具连上数据库，执行select * from v$license;可以查看授权信息。
2. 备份旧 key：把原dm.key改名备份。
3. 上传新的dm.key到安装目录。
4. 重启服务：Windows 重启达梦服务，Linux 执行systemctl restart DmServiceDMSERVER（服务名以实际为准）。
5. 再查一次授权，确认生效。

替换 key 这件事，听起来简单，但很多人栽在权限上。Linux 下如果当前用户对dm.key没有写权限，你cp半天可能根本没覆盖成功。建议用ls -l dm.key先看属主，再chown或者用su到 dmdba 用户操作。

经验：key 出问题时数据库可能还能正常启动，但有些工具有的应用层会报“试用版限制”。DTS 迁移超过一定数据量或遇到某些高级功能报错时，先查授权，别一上来就排查网络和驱动。

3. 实操一条龙：从建迁移任务到数据校验

3.1 新建迁移任务，先理清源库和目标库

打开 DTS 后，主界面会有“新建迁移”“新建同步”这类入口。日常用得最多的是迁移，点开后进入迁移向导。这里不要急着点下一步，先把源库和目标库的连接信息在脑子里过一遍：源库是什么类型、在哪个 IP、什么端口、什么用户；目标库是达梦库，在哪个 IP、什么端口、SYSDBA 还是普通用户、目标模式叫什么。

接下来实际操作：

1. 在“数据源”里选择源数据库类型。比如从 MySQL 迁到 DM，就选 MySQL；从 Oracle 迁到 DM，就选 Oracle。
2. 填写源库连接信息。MySQL 要注意端口默认 3306，Oracle 默认 1521，SQL Server 默认 1433，填错必然连不上。
3. 填写目标库连接信息。目标库固定是达梦 DM，端口默认 5236，用户一般先用 SYSDBA，迁移时再指定目标模式。

这里插一句，很多人会问：能不能在 DTS 里“源库选达梦、目标库也选达梦”？当然可以，这在做达梦库之间数据搬迁时很常见。比如把一套老环境的数据迁到新环境的 DM8，或者把多个分库数据合并到一个库，都是“达梦到达梦”的典型场景。

连接信息填完后，DTS 会做一次连通性测试。如果提示连接失败，先看端口通不通、用户密码对不对、数据库实例能不能正常连接。这时候最忌“什么都填了但都不确定”，建议在命令行telnet一下目标端口，确认网络层是通的。

3.2 表结构、类型映射、主外键：这一页决定迁移质量

连接成功之后，DTS 会让你选择要迁移的对象。页面里能看到源库的模式（schema）、表列表，你可以勾选部分表，也可以全选。很多人在这里直接全选冲到底，但我建议先勾“只迁移表结构”跑一遍，看看类型映射有没有问题，再决定要不要带数据。全量一次到位虽然爽，但遇到批量报错时，定位问题的成本高得多。

选择完对象后，进入类型映射检查界面。这是整个 DTS 里最核心、也最容易被忽略的一步。

达梦的字段类型体系跟 MySQL、Oracle 有差异，比如：

• MySQL 的tinyint到达梦会映射成TINYINT或者SMALLINT，具体看版本；
• Oracle 的NUMBER（无长度）会映射成NUMERIC，如果原表数据量很大，精度可能会有细微差别；
• VARCHAR2通常映射成VARCHAR；
• Oracle 的CLOB对应达梦的CLOB，BLOB也有对应类型。

DTS 默认会给出一套映射关系，大多数情况用默认就行，但你要明白一件事：映射不是 100% 等价。达梦兼容 Oracle 和 MySQL 的部分语法，但毕竟不是相同的数据库。比如NUMBER(38)这种极端精度，迁移后如果应用层强制用某种驱动读取，可能报溢出，那就需要手工把目标字段改成合适的精度。

在 DTS 界面里，你可以点开具体字段，手动修改目标类型、长度、精度。这个操作看起来繁琐，但在遇到源库字段类型不规范（比如 MySQL 里一堆int(11)、varchar(255)混乱定义）时，反而是保证后续应用正常运行的关键。

主键、外键、索引、约束这些，DTS 默认会一并迁移。但有一个问题：如果目标库中已经存在同名表，或者源库表之间有复杂的外键依赖，迁移顺序没处理好，很容易在重建外键时报错。我的做法是，第一遍先只迁表和主键，数据入库后再用脚本补索引和外键。这样即使数据迁移中途失败，也不会因为外键限制导致无法插入。

3.3 迁移参数怎么调：大数据量不卡死的关键

对象和映射都确认了，接下来就是执行层面的参数配置。DTS 提供了一批选项，比如批量提交行数、迁移线程数、是否自动建表、是否迁移数据、遇到错误是否继续等。默认值也能跑，但大库不调参数必吃亏。

说说我常用的几组参数和背后的逻辑：

• 批量提交行数：默认可能是几百或几千行一提交，对大表建议调到 10000 行一次。提交越频繁，事务开销越大；提交太少，事务日志压力又大，迁移速度上不去。别迷信越大越好，批量过大可能导致内存压力上升，特别是表里带大字段时，容易撑爆内存。
• 迁移线程数：DTS 支持并行抽取，线程数太多会占满源库和目标库的 CPU，影响线上业务；太少又跑不快。个人经验是，源库和目标库都空闲的窗口期，可以开到 4 到 8 个并发；如果在生产库上操作，建议保守点，控制在 2 个以内。
• 遇错处理：一定要选择“记录错误，继续迁移”，不要在第一条脏数据上直接停掉整个任务。大库里出现几条异常数据很常见，先跑完整体，再从错误日志里逐个修，比一次次重新跑效率高得多。

数据迁移的过程中，DTS 会显示进度条和计数。我见过有人盯着进度条焦虑的，其实不用急，大批量迁移耗时几十分钟到几小时都正常。真要担心的不是进度慢，而是迁移完之后的校验，那才是见真章的时候。

3.4 迁移完成不等于结束，校验和收尾必须做

DTS 迁移完成，界面会给出成功和失败的任务统计。这里的“成功”只代表“DTS 把数据写进目标库了”，不代表“数据跟源库完全一致”。数据迁移的校验，永远要自己再做一遍。

我最常用的校验手段有三种：

一是行数对比。分别连源库和目标库，对核心大表执行select count(*)，对比行数是否一致。这种方法简单直接，但行数一致不代表内容一致。

二是抽样数据比对。每张表随机抽几条记录，对比关键业务字段。人工比对显然不现实，可以写一个小脚本，或者用数据库管理工具导出小批量数据做 diff。

三是程序化校验。对于严格要求一致性的生产环境，我的做法是：迁移完成后，把源库和目标库的表数据各计算一次哈希值（比如对关键字段做 MD5 或 SHA1），再对比哈希结果。这需要一点开发量，但对金融、政务类系统尤其值得。

校验完成后，还有一个很容易被遗漏的步骤：统计信息更新。达梦的优化器依赖统计信息选择执行计划，数据迁移后表的统计信息可能还是空的，直接跑生产 SQL，可能出现全表扫描导致性能异常。迁移完，记得对关键表执行统计信息收集，比如SP_INDEX_STATS或DBMS_STATS相关过程。细节上的差距，只有在正式上线后才会暴露出来。

4. 常见问题与排查技巧实录

4.1 连接失败、驱动缺失和端口阻塞

DTS 连源库、连目标库，都可能报连接问题。最容易遇到的两个：

第一，驱动缺失。DTS 连接 Oracle、MySQL 时，需要对应的 JDBC 驱动包。达梦默认不一定自带所有第三方驱动。比如连 MySQL，如果 DTS 报 “找不到驱动”，解决方案是手动把 MySQL 的 JDBC 驱动 jar 包放到 DTS 的驱动目录，或者在连接配置里指定驱动包路径。Oracle 也是类似，ojdbc8.jar或者对应版本驱动，放进去就行。

第二，端口不通。很多数据库默认不允许远程连接。MySQL 的bind-address配置、Oracle 的listener.ora、达梦的端口，都需要确保能访问。Linux 下尤其注意防火墙（firewalld/iptables）和 SELinux，一个是端口放行，一个是程序上下文，我遇到过一次 DTS 连达梦报安全拒绝，关掉 SELinux 后问题消失，虽然这种做法不值得推荐，但排查时要知道有这种可能。

4.2 SQL 文件导入、乱码和类型映射的坑

DTS 也可以执行.sql文件导入，很多人把它当成“把别人的库导进去”的快捷方式。实际运行中常见两个问题：

第一，SQL 文件包含源库的方言语法，达梦不认识。比如从 Oracle 导出的.sql里可能带DROP TABLE ... CASCADE CONSTRAINTS、/分隔符等，DTS 直接执行会中途报错。这种情况下，先看报错停在哪个语句，手工把不兼容的语句剥离，再分段执行。

第二，乱码问题。.sql文件保存时的字符集跟 DTS 连接会话的字符集不一致，导入后数据出现?????或乱码。解决办法是在 DTS 的导入设置里显式指定源文件的字符集和连接字符集，比如文件是 GBK，DTS 却默认用 UTF-8 解析，那必然乱。这类问题没有快捷方式，只能多试几种组合，确认目标数据正常后再正式导入。

类型映射上还有一个高频坑：源库里的DATETIME类型带0000-00-00 00:00:00这种非法值。MySQL 里这种值是很常见的（尤其老系统），迁到达梦后直接报“无效的日期时间”。解决思路有两种：一是在迁移前用 SQL 把非法日期统一更新掉；二是在 DTS 的字段映射界面对该字段做处理，或者迁移完成后用 SQL 修正。总之，垃圾数据进库前一定要处理，否则后患无穷。

4.3 迁移后应用层接入：Navicat、Spring Boot 和 MyBatis 的适配

数据迁完，业务系统要连上达梦，很多团队会卡在这一步。网上经常看到有人问 Navicat 连接达梦的问题，我的看法是：直接用 Navicat 原生连达梦并不算官方主推路径，建议优先用达梦自带的管理工具。如果团队必须用 Navicat，通常是通过 ODBC 数据源方式间接连，不要指望 Navicat for MySQL 能直接连达梦并用 MySQL 语法跑。

后端开发这边，Java 项目接入达梦已经很成熟了。Spring Boot + MyBatis + Druid + 达梦，这个组合很多项目在用，核心配置大致如下：

• JDBC 驱动：dm.jdbc.driver.DmDriver，对应的 jar 是DmJdbcDriver18.jar（达梦安装目录或官网驱动的drivers/jdbc下能找到）。
• JDBC URL：jdbc:dm://192.168.1.10:5236，其中 5236 是达梦默认端口，如果库名或模式有要求，可以追加参数，比如jdbc:dm://192.168.1.10:5236?schema=SYSDBA。
• Druid 配置里，driverClassName填驱动类名，initialSize、maxActive等参数按原项目习惯保留。
• MyBatis 的 XML 里如果有品牌方言（比如LIMIT分页写法、dual表引用），需要适配达梦语法。达梦本身做了很多 Oracle 兼容，但 PageHelper 这类分页插件最好用达梦方言配置。

迁移后应用连接不上，先别怀疑 DTS 没迁好，大概率是应用驱动的方言、URL 或权限问题。我遇到过好几次：数据明明在达梦里，但项目启动报ORA-xxxx错误，一看是驱动包还用的 Oracle 驱动，根本没切到达梦驱动。这种低级错误，排查起来却特别费时间。

写在最后的一个建议

做数据迁移这些年，我最大的感受是：工具永远只是工具，真正的坑都在“你以为没问题”的细节上。DTS 能把 90% 的工作自动化掉，但剩下的 10%，比如类型映射的确认、非法数据的清理、迁移后的统计信息更新、应用层的驱动替换，恰恰决定了一个迁移项目能不能平稳上线。建议所有人拿到新环境后，先不要急着迁大表，把 DTS 的连接、授权、映射这些流程在一张小表上完整跑一遍，确认没问题，再放开手干大的。这种先小后大的方式，看起来多花了半小时，实际上能帮你省下大半夜的排查时间。