SyncNavigator 做数据同步时所支持的数据库类型：
支持sqlserver 2000-2014所有版本，全兼容，和MYsql 4.x 、MYsql 5.x 、MYsql 6.x版本。
来源数据库和目标数据库可以版本不同，比如：来源数据库是sqlserver 2012 目标数据库是mysql 5.5 ，都是可以的， SyncNavigator 支持跨数据库版本，无缝传输数据。
只需要能连接上数据库， SyncNavigator 可以安装在第三方电脑上，来源数据库和目标数据库电脑上可以不用安装程序。
事实上，如果我们的系统需要落地数据，尤其是交易型数据，关系型数据库依然是我们的不二选择。在未来相当长的时间里，我们依然会重度依赖关系型数据库。
而在数据库的使用领域，数据同步绝对是一个绕不开的话题。
本文将以大家常见的数据库Oracle和MySQL为例，介绍如何做好数据同步，更确切地讲，是如何做好表数据同步。
一、数据同步涉及的业务场景
在很多业务场景下，我们都有可能会涉及到数据同步，常见的有：
▪ 基于较单纯的同步目的：
由于业务需要，我们就需要把A库的表同步到B库去，这个目的单一且直接。
▪ 出于构建数据总线目的：
我们知道一般系统中都有一个主数据库，该数据库是一个OLTP库，随时接受终端用户的业务请求，对数据库发生CRUD操作。
如果可以构建一个数据总线（Data Bus），在主数据库有变更事件发生时，可以将数据变更同步/传播到其他系统，比如：Memcached/Redis（更新缓存），ES（更新索引），通知其他业务方（某系统对某些表数据的变更事件很感兴趣）。
数据总线机制可以看做是实现数据发布，数据订阅，数据通知的基础载体。
▪ 其他目的：
我们可以通过数据同步实现Master/Slave，实现去O，或者实现异地机房间的数据同步（为了灾备或构建双主机房）等。
二、数据同步的分类
我们可以从不同维度和层面对数据同步进行分类，比如：
▪ 离线同步和在线同步
离线同步指源库已经脱线，不对外提供服务，这也意味着源库数据不会再发生变化。目前市面上的常见的开源同步工具基本都是面向离线同步，比如阿里的DataX。
在线同步则正好相反，源库依然对应用层系统提供数据服务，我们需要在数据不断发生变化的情况下将变化数据同步到其他目的库。这里面的变化包括插入、更新、删除，甚至包括DDL操作（添加/删除字段、修改字段类型、Truncate操作等），每一类变化都不好处理。
由此可见，在线同步比离线同步要复杂得多。
▪ 全量同步和增量同步
全量同步很好理解，就是将当前可以看到的源表上的所有数据一次性全部同步到目的库表（源表数量可能非常大）；而后针对变化的数据，再进行增量同步。
▪ 实时同步、近实时同步和非实时同步
这是从实时性角度的划分，我们当然希望源库变化的数据越快同步到目的库越好。实时性在时间上并没有明确的定义，但一般我们认为基于binlog复制方式的同步是实时的（虽然大多数binlog复制方式是异步发生的）。
对于我们的自研工具da-syncer，在事务量不大的情况下会在1分钟之内将Oracle主站数据同步到其他目的库，可以看做是近实时同步。
非实时同步则对实时性没有太高要求，比如可以是T + 1。
三、数据同步的痛点
无论做何种数据库产品间的数据同步，我们都面临着一些普遍存在的痛点问题，这些痛点问题如果解决不好，会影响数据同步整体准确性和效果。
下面罗列出一些本人遇到的问题，并提供相应解决方案供大家参考。
（1）不同种类数据库字段的类型映射
好的同步工具在做同步任务前会解析源表表结构，并依据源表表结构自动在目的库创建出目的表，然后才进行数据同步操作。
那如何提取出源表的表结构呢？
除了使用JDBC的Metadata接口外，其实更直接更准确的方式是查询源库的元信息表，比如对于Oracle：
SELECT utc.column_id, utc.column_name, t_pk.position, utc.data_type, utc.data_length,
utc.char_length, utc.data_precision, utc.data_scale, utc.nullable
FROM user_tab_columns utc,