1、不同数据库之间的异构数据如何做到无损迁移？Oracle存量数据如何成功迁移至MYSQL、PG等分布式数据库？
@anonym DBA：
如果是迁移至PG的话，可以采用ora2pg+oracle_fdw，可以保证正确性，效率也还可以。或者用DSG的同步软件也能进行数据的迁移，但是在实际使用中，用DSG的来做全库的初始化效率稍微有点差
@韩成亮 KE 数据库管理员：
首先需要确定迁移到数据库的类型，不同的数据库内部结构都是不一样的，需要非常熟悉彼此的差别，其次是需要考虑迁移后的维护问题，高可用的方案，而不是单纯的说 无损迁移。
如果真纯粹是想无损迁移，直接二进制文件导出导入，保证数据不会丢。010101 这种的，数据百分百不会丢失，无非是读取的问题。
如果单纯的考虑表的数据，那么需要详细对比不同数据的字段类型的兼容性。
@standiviny 某保险：
无损迁移存量数据，首先不同数据库有不同的数据类型和支持的功能，迁移前需要梳理清楚，应该就不会有太大问题
2、Oracle数据库迁移至MYSQL、PG等分布式数据库过程中如何保障系统稳定性？如何设置异构数据库并行过渡期？
@泊涯 高伟达公司 系统测试工程师：
系统运营的稳定性，是不是切换过去有一定时间的试运行吧，如果客户允许可以尝试切割方式，分几次迁移，两边都同步运行一小段时间。
@samkingno 北京去哪儿网 数据库管理员：
通过应用双写，在应用控制一致性，确保异构数据库都能运行正常，最后停掉迁移之前的DB。
@standiviny 某保险：
是否接受义务中断？业务是否不同的场景方式不同，建议将场景描述清楚一些，会更容易答复。
3、将业务逻辑实现方从Oracle数据库上移至应用，那么如何评估改造量和改造难度？兼容性如何保障？
【问题描述】Oracle数据库往往和应用耦合度较高，迁移过程还会涉及到应用迁移和改造，特别是存储过程、触发器、自定义函数等方面的改造，将业务逻辑实现方从数据库上移至应用，那么如何评估改造量和改造难度？兼容性如何保障？
@岳彩波 产品经理：
不管系统大小，都要遵循以下原则：
一 、应用评估
确定项目的要求
估计工作量
业务需求分析
分析应用
计划迁移项目
二、应用移植
应用数据迁移
应用软件迁移
应用软件适配新环境
数据库从开发环境移动到生产环境
应用从开发环境移动到生产环境
实施部署策略
三、性能调优
测试数据库和应用程序迁移
进行性能测试和调优
楼主所说的工作量都要经过详细的评估以后才能确定，另外现在有开源的迁移工具和兼容插件，基本上能节省数据和语法迁移的60%时间，可以试试。
4、数据库迁移完成后如何成功建转运？
【问题描述】数据库迁移完成后如何成功建转运？或者说，在数据库设计阶段如何设计运维方案？除了分布式数据库的高可用、负载均衡设计，传统运维方案中的网络、存储、监控告警、备份恢复等等应该如何规划？
@ThinkJ 信泰人寿保险股份有限公司 技术经理：
这是个很大的问题了，涉及到运维的规范和流程等问题。从我们的经验来看，是尽可能的融入到现有的运维体系中，尽量避免大的改造；然后尽早进行培训，以使人员尽快适应变化。
5、Oracle、DB2 迁移至 MYSQL、PG 的 表的限制、数据类型映射关系，如何处理？
【问题描述】（问题来自@冯岩 银行 数据库管理员） 在 Oracle、DB2 到 MySQL的迁移过程中，大家主要关注应用层面的兼容问题。但是，数据类型的映射转换如何处理呢？
我就拿简单的字符串数据类型举个例子吧：
Oracle、DB2 与 MySQL，同样的 utf-8 编码格式，同样的表定义，都包含一个 数据类型 char(10) 的字段。
我要将 “一二三四五上山打老虎” 这个字符串 insert 到这个字段，猜猜会发生什么？
您肯定会说 “一二三四五上山打老虎” 占了 30 byte ，肯定报错的。
但人家 MySQL的 char(10) 就是把这个含着“老虎”的字符串给“吃”了， 而只有 Oracle、DB2 抛出了类似 “ value is too long ”的错误。
为什么呢？因为 Oracle、DB2的 char(10) 最多只能接收10 字节的字符串长度，而 MySQL 人家的 char(10) 的含义是可以存储 10个字符。
看到了吧，其实数据类型的不同之处，还是很值得大家关注的。
MySQL5.7 内置数据类型
DB2 10.1 内置数据类型
@ThinkJ 信泰人寿保险股份有限公司 技术经理：
DSG的同步工具也能做类型的映射和转换，效果也还不错
@anonym DBA：
两种办法：
1.使用工具做转换。譬如：Oracle -> MySQL 的工具: ora2mysql；Oracle->PG: ora2pg
2.对照表梳理出来手工做。
Oracle->MySQL的对照表:
Oralce->PG的对照表：
varchar2 -> varchar
number -> numeric
sysdate -> now()
clob -> text/BYTEA
BLOB -> BYTEA
6、Oracle、DB2 与 MySQL、PG 的 SQL语法有很多不兼容的地方，有什么工具可以完成 SQL的转换吗？
【问题描述】Oracle、DB2传统关系型数据库的 SQL语法 与 MySQL、PG 有很多不兼容的地方。
例如：实现字符拼接的 SQL
Oracle、DB2：
select name || ' is work at ' || dept from employee where empid=10;
而 MySQL：
select concat ( name, ' is work at ', dept ) from employee where empid=10;
有什么工具可以完成 SQL的自动转换吗？
@ThinkJ 信泰人寿保险股份有限公司 技术经理：
要完全兼容Oracle的语法是一件非常困难的事，目前业内兼容Oracle做的比较好的应该是EDB了，阿里云号称兼容Oracle的PPAS实际上就是EDB，DB2的Oracle兼容也是EDB提供的技术，但是从我们实际的测试来看，也还是有很多不尽如人意的地方。所以想完全实现自动转换，基本上没这个可能。不过部分的兼容是可能的，如果是PostgreSQL体系，可以使用诸如orafce这样的插件，还有ora2pg这样的工具，可以实现类型的自动映射，以及存储过程代码部分自动转换，而且ora2pg是perl编写的，很容易实现定制化。
@冯岩 银行 数据库管理员：
EDB 的确是个好动西，之前用过 MKT，迁移 Oracle 到 DB2 的神器。
Oracle 迁移到 DB2，IBM就有类似的工具，实在无法转换，还可以直接启用 DB2 的兼容特性，直接兼容 Oracle的语法。
7、Oracle与mysql 、PG等有些语法、数据类型等略有不同，迁移过去后是否必须要逐条修正？
@冯岩 银行 数据库管理员：
迁移前期，Oracle 与 MySQL 、PG 的 SQL语法兼容性，数据类型间的映射关系就要提前测试验证好。
然后，在测试环境使用准生产数据进行 不断地 迁移演练，不断改善迁移中越到的类似问题。
zymh_zy 国内某公司 IT顾问：
都是关系型数据库，SQL都是共通的。所以，迁移过去，大部份85%都兼容，估计15%要后期调整一下。
8、Oracle数据库迁移至MySQL、PG等分布式数据库后，上层应用是否需要修改，修改的方面有哪些？
@anonym DBA：
是否需要修改，修改那些，多大工作量，这些都非常依赖你目前应用是如何使用Oracle的，具体来说就是使用多少，Oralce中MySQL不擅长或功能弱的东西，譬如过渡依赖数据去解决业务问题，过渡依赖数据库解决大事务问题，触发器等等。
不管什么业务和使用情况，都需要修改几点是：
1.数据类型。Oracle和MySQL不一样的地方。
2.访问数据源驱动。譬如JDBC。
3.部分SQL写法。
zymh_zy 国内某公司 IT顾问：
估计大部份的工作都是放在数据端里修改，应用里会比较少改。因为，是迁移数据库，不是迁移应用。除非是数据库端不能修改，或者修改风险大于修改应用端，才修改应用端。一般都是修改数据库端。
9、如何保证在运行过程中MySQL的高可靠性及高可用性？
【问题描述】1、数据库迁移应该不难，我经历过数据库的迁移2、难的是迁移到mysql数据库后，应该提供怎样的mysql部署架构来提供高可靠性及高可用性？3、mysql的运维认证与oracle相比，应该要弱一些。怎样在生产系统遇到数据库问题的时候，能够得到有效的解决？
@guoxilin 某科技公司 高级非功能测试专家：
我们这边为了保证数据库的健壮性，有针对性做了一些健壮性测试， 比如流水库异常下通应用程序客户端是否迅速得到故障通知，并立即与数据库的正常实例建立新连接，烂SQL下业务健壮性测试，可能存在脏读一些异常场景验证等，目的通过这些健壮性测试和优化，最终实现以下健壮性目标：1. 实际观察故障影响面符合预期 2. 监控告警有效 3. 报错提示和原因的关联性有效 4. 恢复手段有效（若有） 5. 应急手段有效
10、Oracle数据库迁移至MySQL、PG等分布式数据库后，还能逆向回迁至Oracle数据库么？
@ThinkJ 信泰人寿保险股份有限公司 技术经理：
理论上和实践上都是可以的，我们目前的做法就是先用同步工具将Oracle的数据实时同步至PG，切换后，数据同步也反向，即PG数据实时同步至Oracle，这样能保证应用能随时在两套系统中切换，且数据保持一致。不过对开发人员要求就会比较高，需要同时针对两套系统做开发和测试。
11、有没有简单方便的方法将Pg迁移到MySQL？
背景：多个应用由于历史原因有些用pg有些用MySQL。云平台部署后发现pg在自动切换，容灾当面不够完善，运维人员配置mycat只做成MySQL。做主备切换时pg还需人工介入。急切找一种简单方便的方法迁移pg到mysql。
@standiviny 某保险：
1、可用DATAX 类的ETL工具，使用方便，效率还可以，对于不太熟悉其他工具的，建议此方法
2、部分客户端软件支持异构同步
@刘建清 中国建材 系统运维工程师：
简单的方法就是直接用postgre导出sql，用sql再导入MySQL，也可以用外部dblink的方式引入外部数据源试试。
复杂可靠一点的可以用第三方工具。支持异构数据库备份和恢复和同步的工具很多，DSG，OGG等。
迁移时主要注意几点：
一、数据量大小；
如果数据量很小，且只有简单的几个表的话，直接用表导出sql的方式，就可以实现。
数据量大的话，需要考虑导出文件的大小和存储方式，要不备份时间会很长。
二、 迁移数据传输方式；
迁移时，是否用外部存储，网络传输？或都其它方式都影响效率。
三、 应用兼容支持情况；
迁移到mysql后看是否有新的应用支持,需要做好测试工作。
@ThinkJ 信泰人寿保险股份有限公司 技术经理：
pgpool除了能做PG的负载均衡、读写分离，也能做主备的自动切换。而且更强大的是pgpool对使用了函数的sql也能做负载和读写分离，建议可以尝试使用下
12、MySQL、PG属于分布式数据库吗？怎么区分数据库是否为分布式？
@samkingno 北京去哪儿网 数据库管理员：
应该这么说，基于MySQL 和 postgresql 数据库的分布式架构
类似的产品有 citus 和 greenplum，都是基于postgresql 的分布式数据库产品
@fengshaoyi JSHBANK 应用保障工程师：
区分是否为分布式数据库的关键标准在于数据库计算节点是否支持横向的无限扩展，即通过计算节点的扩展可以实现不拆分数据库的情况下的数据库运算能力的提升。如果可以，则该数据库为分布式数据库，否则不是。常见的分布式数据库基本模式是计算单元和存储单元分离，以支持横向扩展。
