数据库迁移到达梦的一些记录

1 达梦迁移工具
参考MySQL迁移到达梦-超出定义长度问题

使用你设置的配置，即可，因为达梦默认采用按照字节存储，mysql是按照字符存储，故而他认为越界了。

使用3.5G数据，342张表进行数据迁移验证
第一此执行,结果

 任务总数:8,133, 完成:7,903, 出错:225, 取消:5, 耗时:2分56秒417毫秒

达梦8 数据迁移报错汇总
下面id、pid、level字段显示无效的列名，更是奇怪，数据都已经写进去了，为何还是这样的错误呢？还有如果说是字段名的问题，但另一张表跟他字段一样，却不报错呢？如果这么推理的话，问题应该出现在字段类型。删除数据，重新导入，居然又不报错了。
如此看来，最好不要一次性全量执行，采取分批导入。


MySQL 中 varchar(1) 可以存一个汉字，DM 数据库是以字节为单位。gb18030 字符集，varchar(2) 才可以存一个汉字；UTF-8 字符集，varchar(3) 才可以存一个汉字。

下面的这个错误，通过初始化数据库的时候，设置VARCHAR以字符为单位即可

出现form长度超出定义

检查数据发现，char(2)的字段里面有中文，导致字段超长

初看很奇怪，细想应该是mysql表中创建索引存在不符合常规的情况

检查mysql数据库表,同一个字段，居然又两个索引，只是名字不同，mysql中随意，但是达梦数据库可不惯着你。

注意重新执行，要勾上下面的，因为表和数据实际已经写入到数据库中了。

特别注意，达梦数据库创建实例时,字符集使用GB18030，字符串比较大小写敏感，这样varchar和char的长度问题就解决了，不需要像上面说的做强制转换

另外迁移的时候，可以保持大小写,否则会将你的表名、字段名全部设置为 大写，按照下图中的设置，就跟java的习惯保持一致。

在导入前可以做一些分析，不过在我看就是一个统计，暂时还没发现作用是啥，超大记录会用到？

2 使用kettle迁移数据到达梦
参考Kettle连接达梦数据库
kettle做迁移，做转换、比对挺好，更加灵活，但是单纯的数据迁移，还是达梦数据库自己的工具笔记好。

将驱动文件复制到kettle的安装目录中

如果是本地的，先确认dm数据库是否启动了

接着再kettle中配置达梦的数据库连接