OpenGauss 510与Oracle的兼容性如何？你试过了吗？

目前使用openGauss或者基于openGauss的国产数据库的客户已经不少了，当我们要把一套数据库从Oracle迁移到openGauss的时候，首先我们要关注的是openGauss与Oracle的兼容性如何。一些基于openGauss的商用数据库在兼容性方面做了一定的增强，有些号称兼容性已经超过90%，不过我没有亲身体验过，不知道是否属实。对于openGauss 5.10，大致的 兼容度评估如下表：

其中操作符的兼容性是100%，其他的兼容性都还有一定的差距。DML兼容性接近70%，PL/SQL的语法兼容性接近80%，从这两个指标上看，应用迁移难度也不算太大，但是想要平替是不大可能的。数据类型的兼容度只有63.41%，这是个比较麻烦的事情。    

不过幸运的是，这些不兼容的数据类型在国内的应用中使用较少。NCHAR/NCLOB可以通过转换工具进行转码，LONG/LONG RAW自从LOB出现后也很少被使用了，如果还有少量使用，可以通过工具转为LOB字段即可。ROWID在早期的一些应用中，为了优化性能被使用得还是挺多的，这方面的应用只能重新寻找新的优化方案了。TIMESTAMP是比较容易被忽视的问题，因为精度的问题，某些应用在迁移后，需要对这方面的功能进行校验。BFILE虽然用得不是很多，不过我还是见过一些的，一些10年以上的老系统，为了让一些只读的的大对象不影响数据库性能，使用了BFILE。这方面的应用改造还是有点工作量的。

系统视图的兼容度最低，不过这方面想要改善比较容易。系统高级包的兼容度也比较低，如果应用中对Oracle的高级包有重度依赖，那么迁移改造 工作量还是很大的。从总体上来看，openGauss 5.1.0在Oracle兼容性方面的提升比较慢，相比5.0.1的总体兼容度34%出头，相差并不大，只是在系统兼容包方面有了小的提升。看样子openGauss是把与Oracle的兼容性都留给了生态商用产品了。    

今天简单给大家分享了一下openGauss与Oracle的兼容性的一些统计数据。总体上来说，从Oracle向openGauss迁移还是可行的，不过对于大多数应用来说，不可能简单平替。当然，基于openGauss的商用产品在这方面会做得更好，愿意掏银子的用户，选着海量Vastbase G100、恩墨MogDB、南大通用Gbase 8C等基于openGauss的商用数据库，迁移难度会略低一些。其中Gbase 8C不光有集中式版本，还有类似于GaussDB的分布式版本。