达梦数据库笔记之数据迁移工具DTS（MySQL_to_DM8）

需求：把MySQL类型的某个数据库里的所有数据即所有表，迁移到达梦数据库里。

步骤一、新建工程

步骤二、新建迁移

右键点击项目下的迁移节点 → 选择新建迁移任务；

步骤三、选择方式

在向导里选择迁移方式；

步骤四、源数据库

输入Mysql数据库信息；

注意：数据库名把默认改为你需要迁移的数据库名比如test数据库，而不是默认的 mysql 系统库。

点击刷新，在后续步骤才能通过勾选源模式获取该数据库所有表。

步骤四、目标数据库

输入达梦数据库信息；

步骤五、迁移数据

模式：要把 MySQL 里的哪个库（比如 test）作为迁移的源。
模式对象：这个库里的哪些具体对象（比如所有表、视图、存储过程）需要迁移。

（1）核心选项

用一条或多条查询指定要迁移的数据：这个选项适合只迁移部分数据（比如用 WHERE 条件筛选），不是全表迁移。
从数据源复制对象：这个选项是直接复制整个表结构和数据（把 test 的所有表完整迁移）。

（2）表格区域

这是选择具体要迁移的数据库对象的地方：

源模式：这里对应你的 MySQL 数据库 test。
目的模式：对应达梦数据库里要接收数据的目标模式（可以是已存在的，也可以新建）。
创建模式：勾选后，会在达梦自动创建和源模式同名的模式（库）。
表 / 视图：勾选后，会把源库中所有的表 / 视图都迁移过去。

（3）右上角选项

应用当前策略到其他对象
这个选项是当你同时迁移多个源模式时，把当前这一行的配置（比如目标模式、大小写转换）批量应用到其他所有行。现在只迁移一个模式，所以暂时用不上。
保持对象名大小写（K）
未勾选：工具会自动把 MySQL 里的小写表名 / 字段名（比如 a_authority、group_id）转换为达梦里的大写（A_AUTHORITY、GROUP_ID），完美解决大小写不匹配的问题。
如果勾选，会保留原有的小写名称，导致后续外键 / 约束报错。

（4）勾选表与视图

把 MySQL 源数据库里的表和视图这两种对象，完整地复制到达梦数据库里。

（5）编辑目的模式

双击 "目的模式" 列下显示 SYSDBA 的单元格，进入编辑状态。
直接输入TEST（达梦默认大写，和你的 MySQL 库名如test保持一致）。
勾选 "创建模式" 这一列的复选框，工具会在迁移时自动创建 TEST 这个模式，无需手动提前创建（如果提前已在DM管理工具里创建了TEST，直接在下拉框里选择即可）。
输入完成后，按 Enter 键确认，然后点击「下一步 (N)」继续迁移流程。

步骤六、迁移对象

点击左下角的「选择 (S)」按钮会一次性全部勾选上。

步骤七、进行迁移

点击完成进行迁移。

DM管理工具里右键模式刷新即有该数据库了。

问题：大小写不匹配

（1）问题原因

达梦数据库在迁移时，给 A_AUTHORITY 表添加 CHECK 约束时失败了，核心原因是大小写不匹配。

类似无效的列名 [group_id] 问题：

外键约束在迁移时，因为达梦默认把字段名转成大写，导致约束语句里的小写 group_id 找不到达梦里的大写 GROUP_ID
字段，从而报错。
解决方法就是在达梦里创建约束时，把字段名写成大写的 GROUP_ID。

sql 复制代码

SELECT
  CONSTRAINT_NAME,
  COLUMN_NAME,
  REFERENCED_TABLE_NAME,
  REFERENCED_COLUMN_NAME 
FROM
  INFORMATION_SCHEMA.KEY_COLUMN_USAGE 
WHERE
  TABLE_SCHEMA = 'test' 
  AND TABLE_NAME = 'a_authority';

第一行（PRIMARY）：这是表的主键约束，说明 id 字段是 a_authority 表的主键，用来唯一标识每条权限记录。
第二行（a_authority_ibfk_1）：这是一个外键约束，它表示： a_authority 表的 group_id 字段，引用了
a_authority_group 表的 id 字段。这是一个典型的 "多对一"关联：多个权限可以属于同一个权限组，保证了数据的一致性。

（2）解决方法

首先在Dmitri管理工具里把迁移创建的TEST数据库删除，如果失败，勾选级联删除即可。

因为模式里包含了相互关联的表（比如外键依赖），达梦为了保护数据完整性，要求你使用「级联删除」才能完整删除整个模式。

先导出失败的约束信息
在迁移日志里，点击 "查看详细信息"，把所有失败的 CHECK 和外键约束的语句复制出来。
批量转换为大写字段名
用文本编辑器的 "替换" 功能，把这些约束语句里的小写字段名（如 user_id、group_id）全部替换成大写（USER_ID、GROUP_ID）。
执行修复脚本
把修改后的约束语句复制到达梦查询工具里执行，就能一次性修复所有失败的约束。

在DM管理工具里新建查询；

先手动确认约束是否存在
执行这条 SQL 查询，看看哪些约束是实际存在的；

sql 复制代码

SELECT CONSTRAINT_NAME, TABLE_NAME
FROM ALL_CONSTRAINTS
WHERE OWNER = 'TEST'
AND TABLE_NAME IN ('A_AUTHORITY', 'A_ROLE_AUTHORITY', 'A_USER_INFO', 'A_USER_QUESTION', 'A_USER_ROLE');

根据查询结果，生成删除约束的 SQL
用查到的约束名，替换下面脚本里的 CONSTRAINT_NAME：

sql 复制代码

-- 删除存在的旧约束
ALTER TABLE "TEST"."A_AUTHORITY" DROP CONSTRAINT "CONS134218862";
ALTER TABLE "TEST"."A_ROLE_AUTHORITY" DROP CONSTRAINT "CONS134218865";
ALTER TABLE "TEST"."A_USER_INFO" DROP CONSTRAINT "CONS134218867";
ALTER TABLE "TESTZ"."A_USER_QUESTION" DROP CONSTRAINT "CONS134218868";
ALTER TABLE "TEST"."A_USER_ROLE" DROP CONSTRAINT "CONS134218869";

执行这段脚本，就能把所有旧的、错误的约束都删掉了。

运行重建约束的脚本
然后执行重建脚本，用正确的大写表名和字段名，重新创建所有约束（不知道没有别的方案。。。）。