银行交易型应用从Oralce/Db2迁移到国产数据库，各个国产数据库数据迁移的能力情况怎么样？

这个题目有点矛盾，真正的银行系统的替换是需要比较长时间的磨合和打磨，然后再停业务寻找时间窗口去做迁移，再开业。
所谓在线迁移也就是一个理想情况罢了。

国产数据库对于oracle和db2的兼容性，其实在国内我一直认为是一个病态的存在。
因为无论怎么说，几百家的国产数据库的核心不是pg就是mysql，在全球OLTP数据库排名前十的数据库都哪里存在兼容性的事情，不就是参考SQL标准罢了。

我们所谓的O兼容，不过是应用开发商省事罢了。
从国内的项目生态来看，应用开发商的费用比例占大头，现在已经基本上成了客大欺店的形态。

另外从实际情况来看，虽然每家国产数据库都说自己兼容O百分之多少多少，但是从来不会给客户提供详细的功能支持清单。换言之，O的功能确实很多很多很多，我们基本上上就O的一个局部，客户其实恰恰用的也就是O的一个局部，大家也就稀里糊涂的过吧，没法直面Oracle的。

再换一个角度考虑，我们功能可以兼容Oracle，价格又好，岂不是可以出海去挣美元英镑了？明显并非如此

虽然多数厂商都会提供数据库迁移的工具。不过终究数据库是一个比较庞大而复杂的系统。特别是在很多行业和应用中都难免会有些独特的设计，迁移工具对于通用性的功能上应该是可以胜任的。但往往这些特有的设计和使用方式无法做到通用。可能需要在实际的项目中要具体情况具体分析了。想要通过一种万能工具来实现从现有数据库迁移到国产数据库的完全自动化。我觉得可能不会太乐观。或多或少的都会有各种实际的问题要去解决。所依迁移之前的评估，测试就尤为重要。

我们做国产数据库选型时，一般会看它们对Oracle的兼容性。很多国产数据库都会声称，自己对Oracle的兼容性能达到百分之九十几。那到底是百分之九十几呢？其实这个准确的数据无需较真，因为剩下的百分之几也都是我们在迁移过程中经常会碰到的东西，为了做好迁移工作，我们少不了需要一定的借力。
这时就需要利用一些工具，比如代码扫描工具、SQL抓取工具等。我们联合了一些第三方的厂商，让他们按照我们的需求开发一些工具，使用这些工具扫描代码就能把里面的SQL全部扫描出来，或者扫描数据库，无论是生产环境还是测试环境的，都可以把曾经跑过的SQL全部找出来。当拿到这些东西之后，我们再放到一个评估的工具里去验证，原来的语法是否能在新的数据库里执行。对于不能够执行的语法，则需要推荐一些建议去进行改造。
所以这些工具的成熟与否，跟我们迁移改造的过程是否顺利息息相关。工具如果好用，迁移起来就更便捷，如果不好用，那很多时候都需要人为判断、人为寻找替代方案，甚至人为地把整个应用进行改造，而不仅仅是改造SQL。

金融行业目前都是做双向同步，完了把国产数据库先作为备库去验证完之后才正式承载业务的吧，没有一上来就把国产数据库做生产的，而且即便迁移了原来的数据库还会并行用一两年，做逃生库。

迁移是一个重点，这个厂家会提供支持，但是与程序的适配即对源数据库的兼容是需要考虑的重点，钱以后程序能否平稳允许起来需要长时间全覆盖的测试。

很多是支持单向迁移的，问题是否前期做好整体的评估。迁移的话场景基本上都是有工具和办法的，回来就不好说了。

迁移工具厂商都会提供，迁移进度还要看数据能否实时双向同步。