mysql 数据迁移工具(Server到MySQL四款主流数据库迁移工具对比)
mysql 数据迁移工具(Server到MySQL四款主流数据库迁移工具对比)同时为了测试的公平性,除 Mss2SQL 外,所有软件都是直接从官网下载最新的版本。 Mss2SQL 由于试用版的限制原因没有参与测试,而使用了网上唯一能找到的 5.3 破解版进行测试。MySQL 服务配置:用于测试的源数据库名为 MesoftReportCenter。由于其中一个测试工具试用版限制只能处理两张数据表的原因,因此我们只选取了记录数最多的两张数据表:HISOPChargeIntermediateResult 和 HISOPChargeItemIntermediateResult。两张数据表合计的记录数约为 328万,数据库不算大,但针对本次进行测试也基本上足够了。SQLServer 服务器和 MySQL 服务器分别运行在两立的虚拟机系统中,而所有的待测试程序都运行在 MySQL 所在的服务器上面。其中:SQLServer 服务配置:
在部署前期,首要任务就是考虑如何快速把基于 SQL Server 数据库的应用程序移植到阿里云的 MySQL 数据库。由于程序是基于 O/R mapping 编写,并且数据库中没有使用存储过程、用户函数等数据库功能,因此仅仅需要考虑的是数据库中的数据如何转换到新的 MySQL 数据库中。
通过度娘查找,找到如下四种可以使用的工具,并且每一种工具都有大量的用户,还有不少用户在自己的博客中写下了图文使用经验,这四种工具分别是:
- SQLyog
- Navicat Premium
- Mss2sql
- DB2DB
由于公司需要处理的是业务数据库,因此必须保证数据转换的准确率(不允许丢失数据,数据库字段、索引完整),并且需要保证数据库迁移后能立即使用。因此在实施数据迁移前,对这几种 SQLServer 到 MySQL 的迁移工具进行一个全面测试。下面我们将基于以下需求为前提进行测试:
- 软件易用性
- 处理速度和内存占用
- 数据完整性
- 试用版限制
- 其它功能
一、测试用的源数据库和系统
用于测试的源数据库名为 MesoftReportCenter。由于其中一个测试工具试用版限制只能处理两张数据表的原因,因此我们只选取了记录数最多的两张数据表:
HISOPChargeIntermediateResult 和 HISOPChargeItemIntermediateResult。两张数据表合计的记录数约为 328万,数据库不算大,但针对本次进行测试也基本上足够了。
SQLServer 服务器和 MySQL 服务器分别运行在两立的虚拟机系统中,而所有的待测试程序都运行在 MySQL 所在的服务器上面。其中:
SQLServer 服务配置:
- 操作系统:Windows XP
- 内存:2GB
- 100MB 电信光纤
MySQL 服务配置:
- 操作系统:Windows XP
- 内存:1GB
- 100MB 电信光纤
同时为了测试的公平性,除 Mss2SQL 外,所有软件都是直接从官网下载最新的版本。 Mss2SQL 由于试用版的限制原因没有参与测试,而使用了网上唯一能找到的 5.3 破解版进行测试。
二、软件易用性评测
软件易用性主要是指软件在导入前的配置是否容易。由于很多软件设计是面向程序员而非一般的数据库管理人员、甚至是普通的应用程序实施人员,而这一类人员很多时候并没有数据源配置经验。因为一些使用 ODBC 或者 ADO 进行配置的程序往往会让这类用户造成困扰(主要是不知道应该选择什么类型的数据库驱动程序)。下面让我们看看四个工具的设计界面:
>>>>
1、SQLyog
SQLyog 使用的是古老的 ODBC 连接,但对于新一代的程序来说,这种方式的非常的不熟悉并且不容易使用,并且必须要求本机安装好相应的数据库的 ODBC 驱动程序(SQL Server 一般自带好)。
>>>>
2、Navicat Premium
Navicat Premium 是四个应用工具中设计最不人性化的一个:从上图怎么也想像不到要点按那个小按钮来添加一个新的连接,并且这个连接设置不会保存,每次导入时都必须重新设置。 Navicat Premium 使用的是比 ODBC 稍先进的 ADO 设置方式(199X年代的产物),但使用上依然是针对老一代的程序员。
>>>>
3、Mss2sql
Mss2sql 是最容易在百度上搜索出来的工具,原因之一是它出现的时间较早。
Mss2sql 由于是很有针对性的从 SQLServer 迁移到 MySQL,因为界面使用了操作向导设计,使用非常容易。同时在设置的过程中,有非常多的选项进行细节调整,可以感觉到软件经过了相当长一段时间的使用渐渐完善出来的。
>>>>
4、DB2DB
DB2DB 由于是由国人开发,因此无论是界面还是提示信息,都是全程汉字。另外,由于 DB2DB 在功能上很有针对性,因为界面设计一目了然和易使用。和 mss2sql 一样, DB2DB 提供了非常多的选项供用户进行选择和设置。
三、处理速度和内存占用评测
在本评测前,本人的一位资深同事曾经从网上下载了某款迁移软件,把一个大约2500万记录数的数据表转送到阿里云 MySQL,结果经过了三天三夜(好在其中两天是星期六和星期日两个休息日)都未能迁移过来。因此这一次需要对这四个工具的处理速度作一个详细的测试。
考虑到从 SQL Server 迁移到 MySQL 会出现两种不同的场景:
- 从 SQL Server 迁移到本地 MySQL 进行代码测试和修改;
- 从 SQL Server 迁移到云端 MySQL 数据库正式上线使用;
因此我们的测试也会针对这两个场景分别进行评测,测试结果如下(记录数约为 328万):
注:红色字体标识为胜出者。
以下为测试过程中的截图:
>>>>
1、SQLyog
>>>>
2、Navicat Premium
注意:我们在测试 Navicat Premium 迁移到 MySQL 时发现,对于 SQL Server 的 Money 类型支持不好(不排除还有其它的数据类型支持不好)。Money 类型字段默认的小数位长度为 255,使得无法创建数据表导致整个测试无法成功,需要我们逐张表进行表结构修改才能完成测试过程。
Navicat Premium 的处理速度属于中等,不算快也不算慢,但 CPU 占用还有内存占用都处于高位水平。不过以现在的电脑硬件水平来说,还是可以接受。但 CPU 占用率太高,将使得数据在导入的过程中,服务器不能用于其它用途。
>>>>
3、Mss2sql
Mss2sql 并没有提供计时器,因此我们使用人工计时的方法,整个过程处理完毕大于是 726 秒。Mss2sql 的 CPU 占用率相对其它工具来说较高,但仍属于可以接受的范围之内。
>>>>
4、DB2DB
DB2DB 同样迁移 300万数据时,仅仅使用了 2 分 44 秒,这个速度相当惊人。不过最后的结果出现一个 BUG,就是提示了转换成功,但后面的进度条却没有走完(在后面的数据完整性评测中,我们验证了数据其实是已经全部处理完毕了)。
四、数据完整性评测
数据准确无误地从 SQL Server 迁移到 MySQL 应该作为这些工具的一个基本要求,因此这里我们对四种工具转换之后的结果进行检查。
我们通过后台 SQL 对记录数进行检查,发现所有的工具都能把记录完整地迁移到新的数据库。如果仔细观察,可以发现上图中各个数据库的大小是不一致的,基本的判断是由于各种工具在映射数据表字段时,字段长度取值可能不能而引起的。而 mesoftreportcenter2 数据库大小比起其它数据库差不多少了一半,这引起了我们的注意。通过分析,我们发现 Navicat Premium 在迁移数据库时,并不会为该数据库所有数据表创建索引和主键,缺少索引和主键的数据库大小显然比其它数据库要少得多。
为了解各工具迁移后的数据库能否立即应用于生产环境,我们对创建后的数据表进行了更深入的分析,发现各工具对字段默认值的支持程度也不尽相同。其中:
- SQLyog:完整支持 SQL Server 的默认值;
- Navicat Premium:完全不支持默认值,所有迁移后的数据表都没有默认值;
- Mss2sql:支持默认值但有严重错误;
- DB2DB:完整支持 SQL Server 的默认值。
Mss2sql 的默认值有一个严重的错误,在 SQL Server 中字段默认值为空字符串 '',但迁移之后变成两个 '' 符号。Mss2sql 这个严重的错误会使得程序在正式环境运行后,数据库会产生错误的数据!
在一些老旧的系统中,数据库还会存在 Text、二进制类型的字段数据,通过测试对比后,四种工具都完美支持 Text 和 二进制(Image)类型字段。
>>>>
小结:
五、各工具其它功能及试用版限制
估计由于数据库同步会存在一些技术难题的原因,4 款工具目前都是只是提供试用版本,最后我们来看看四个工具的试用版本各自的限制是什么:
四种工具中,由于 SQLyog 和 Navicat Premium 提供了额外的管理功能,所以价格相比其它两款工具的要高得多。特别是 Navicat,必须是 Premium 版本才提供数据转换的功能。而 Mss2sql 最新版本的试用版只提供了 50 秒处理时间,因为实用价值不大。而笔者与 DB2DB 作者联系时得知,DB2DB 设置 10万记录限制,主要是考虑国内很多小型软件记录数都是少于 10 万笔,而这一类人群一般都是小型创业团队。
六、评测总结
最后,对四款软件的测试结果作一个整体的总结:
以上四款软件中,最不推荐使用的是 Navicat Premium,主要原因是数据的完整性表现较差,转换后的数据不能立即用于生产环境,需要程序员仔细自行查找原因和分析。而 SQLyog 有较好的数据完整性,但整体处理速度非常的慢,如果数据较大的情况下,需要浪费非常多宝贵的时间。比较推荐的是 DB2DB,软件整体表现较好,对我来说最重要的是在不购买的情况下也够用了,而且全中文的傻瓜式界面操作起来实在方便。
来源:博客园
作者:青出于蓝
附触发器实现局域网内SQLServer之间的数据实时同步
准备工作:
1.启动两台服务器上的Distributed Transaction Coordinator服务(开始--运行--services.msc 回车,找到前面的这个服务--启动)
2.MSDTCMSDTC设置
windows server 2003设置:
windows server 2008设置:
3.检查防火墙。可以关闭防火墙或把MSDTC加入例外。
4.检查两台服务器通信是否正常:
a) telnet DbIP 135是否可以通;b) 然后相互Ping IP;c) 再ping 相互的NetBios名称(输入ping -a ip就可以看到对应的NetBios名称),还不通的话可以修改%windir%/system32/etc/hosts,或%windir%/system32/etc/lmhost.sam去掉文件扩展名,进行DB服务和IP的绑定即可。
如下图所示:
数据库服务器“属性”——“链接”——”需要将分布式事务用于服务器到服务器的通讯”前打钩
到这里通过触发器进行数据库分布式开发的环境就准备好了。
实现功能:
1.确定两台数据库服务器上要进行同步的数据库及表结构.
2、建立两个数据库之间的链接服务器,在数据发布端建立,
exec sp_addlinkedserver 'bbb(链接服务器名,随便写)' '(这里一个空的引号,不能忘记)' 'SQLOLEDB(固定写法)' '172.18.6.204(被同步数据库的Ip)' ---------------建立局域网连接服务器
exec sp_addlinkedsrvlogin 'bbb(链接服务器名)' 'false' null 'sa' 'Axny123456' (被同步数据库账户密码)----------------链接服务器登录
3、在需要发布端的表格上建立触发器(需要注意的是对应好相应的字段和表名),并执行该语句(以插入为例)。
USE [Test]
GO
/****** Object: trigger [dbo].[TOOOO] Script Date: 05/26/2018 11:12:56 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET XACT_ABORT ON
GO
-- =============================================
-- Author: <Author Name>
-- Create date: <Create Date >
-- Description: <Description >
-- =============================================
CREATE TRIGGER aaa
ON [dbo].[student]
FOR INSERT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for trigger here
insert [bbb].[test].[dbo].[Student](StuId StuName StuClass StuAge) select id name class age from inserted;
END
4、在发布端的数据表中插入一条数据,在被触发端的数据库相应表中你就会看到同步的一条数据了。