都说国产数据库90%兼容Oracle，为何迁移过程中总遇难题？

都说国产数据库90%兼容Oracle，为何迁移过程中总遇难题？-51CTO.COM

Q1 目前国产数据库与Oracle相比主要欠缺在哪些方面？

孔再华：我所在的民生银行正在做数据库国产化改造，选型时全面分析了国产数据库相比于Oracle等传统商业数据库的欠缺之处。

一、性能。我们看到目前国产数据库在性能上多数会偏重于某个方向，有些是OLTP的性能较好，有些则是OLAP的性能较好，所以从HTAP的角度来说，国产数据库与Oracle相比还是存在一定的差距。

但也不妨从另一个方向考虑：我们是不是因为性能这个问题才做国产化改造的呢？显然不是。所以我们需要解决的是怎样去克服数据库国产化的性能问题。一方面，不同性能类型的数据库，需要采用不同的国产化方案；另一方面，像分布式数据库、内存数据库这样一些超融合的数据库，也是可以“弯道超车”的地方，我们可以将自身的需求融入到这些数据库里进行改造和实现。

二、功能性。Oracle等传统商业数据库经历了几十年的发展，功能已相当成熟，周边生态也非常完善，这些对于“年轻”的国产数据库来说还有很长的路要走。

在这个问题上，目前国产数据库可粗略分为两种类型，一种是研发之初就朝着接轨Oracle生态的方向，照着Oracle的功能做一遍，总体来说可能做到80%-90%，还存在一定欠缺；另一种则是跟Oracle完全不同，但其实数据库在保障性能和主要功能的前提下，有很多功能差异是很正常的，比如Oracle和DB2就是很不一样的两款数据库，所以我们也不能仅仅参照Oracle来做对比。

当然这些功能差异也是我们需要克服的困难，对于原本用得很熟练的功能，国产化后我们可能需要另找一些替代方案，甚至联合一些国内厂商或第三方厂商去改善这些功能和生态环境。所以国产数据库在功能性方面的欠缺，需要大家共同努力。

三、可用性。像Oracle这么成熟的数据库，在每次新版本发布时都还会有大量bug的修复，但由于目前国产数据库的使用率还不算高，大家探坑的机会也就不多，使用起来才发现有不少bug也是可以预见的情况。所以在可用性这方面同样需要大家共同努力，一起去踩坑，一起将国产数据库推向更好的方向。

Q2 Oracle往往与应用耦合度较高，迁移过程中会涉及应用迁移和改造，如何评估改造量和改造难度？如何保障兼容性？

孔再华：这是一个非常好的问题，也是我们目前面临的最大痛点。我们银行之前在使用Oracle的过程中，在应用开发时大量使用到Oracle提供的一些功能，国产化后就面临着很大的改造难度。所以说，怎么进行改造和迁移？怎样评估改造难度？确实是很关键的问题。

我们做国产数据库选型时，一般会看它们对Oracle的兼容性。很多国产数据库都会声称，自己对Oracle的兼容性能达到百分之九十几。那到底是百分之九十几呢？其实这个准确的数据无需较真，因为剩下的百分之几也都是我们在迁移过程中经常会碰到的东西，为了做好迁移工作，我们少不了需要一定的借力。

在应用改造迁移方面，我们最大的难点是：怎样评估应用里有哪些东西是不兼容的？

这时就需要利用一些工具，比如代码扫描工具、SQL抓取工具等。我们联合了一些第三方的厂商，让他们按照我们的需求开发一些工具，使用这些工具扫描代码就能把里面的SQL全部扫描出来，或者扫描数据库，无论是生产环境还是测试环境的，都可以把曾经跑过的SQL全部找出来。当拿到这些东西之后，我们再放到一个评估的工具里去验证，原来的语法是否能在新的数据库里执行。对于不能够执行的语法，则需要推荐一些建议去进行改造。

所以这些工具的成熟与否，跟我们迁移改造的过程是否顺利息息相关。工具如果好用，迁移起来就更便捷，如果不好用，那很多时候都需要人为判断、人为寻找替代方案，甚至人为地把整个应用进行改造，而不仅仅是改造SQL。

在数据库迁移方面，金融行业很多数据库都是7*24小时工作的，我们并没有太多时间去做离线的数据迁移，所以要评估在数据迁移的过程中，DDL的对象过去是否可行？数据离线的时间是否被允许？

关于DDL的对象，首先，从Oracle迁移到国产数据库，肯定有相关材料介绍一一对应的关系。然后，需要一个迁移工具，这个工具负责将原有Oracle里的字段类型、对象，转换成国产数据库的对象。经评估，现有的开源工具和商业工具，对于我们迁移到国产数据库中的一些规则类型的改造都稍显不足，所以我们跟相关的厂商合作，把这些规则梳理好、把相应的工具造出来，并且在我们迁移过程中不停加以完善，这个工具就会变得越来越好使。

由此，我们在DDL的转换上问题就不大了，但接下来问题比较大的是存储过程这块，还有一些用到Oracle自身函数的东西。同样的，我们也需要进行详细的梳理，然后打造相关的工具。其实我们以往不推荐大家去使用存储过程，因为使用了存储过程就相当于跟对应的数据库绑定了。我们一直推荐大家简单地使用数据库，因为数据库作为后端最核心的一个提供服务的组件，需要很高的可用性，所以还是要尽量给数据库减负，而不是一味地依赖数据库的这些能力。如果之前已经这么干了，就只能通过工具，逐个发现不适合的地方进行改造。如果未来自己有机会做新数据库的开发，一定要避免使用触发器、存储过程等这些跟数据库耦合度很高的东西。

当解决了这些问题之后，接下来就是关于数据迁移这块。如果是从Oracle迁移到其它数据库，可能会有些不错的方法可以做在线迁移。因为Oracle本身或者一些第三方厂商都具有在线迁移工具，这些工具会通过扫日志的方式同步数据，然后在需要做切换时，停业务同步最后一段数据，切换业务到新的国产数据库。

但也有可能这些工具并不支持你选用的国产数据库，这种情况就需要单独造一个离线工具进行评估，从Oracle到国产数据库里怎么改造。最好还是找厂家协助写一个在线迁移工具，这个在线迁移最好不要落地，能够去并发、不落地地将Oracle的数据查询出来，放到国产数据库里去。

对于一些特别大的表，我们可能还需要提高它的并发，还需要工具提供单表并发的功能。通过写一定的查询语句，把单表里的内容拆成更多份，然后每一份之间再进行并行，提高迁移速度。

总体来说，做替代Oracle的国产化改造其实非常困难，但这注定是一个任务，是一个目标，我们就是要这么去干！以上我所讲述的，就是怎么在各环节采取合适的方式来加快国产化改造的建议，希望能对大家有所启发。