目前使用openGauss或者基于openGauss的国产数据库的客户已经不少了，当我们要把一套数据库从Oracle迁移到openGauss的时候，首先我们要关注的是openGauss与Oracle的兼容性如何。一些基于openGauss的商用数据库在兼容性方面做了一定的增强，有些号称兼容性已经超过90%，不过我没有亲身体验过，不知道是否属实。对于openGauss 5.10，大致的 兼容度评估如下表：
编号 | 特性名称 | 兼容 | 不兼容 | 总数 | 百分比 |
1 | DCL关键特性 | 48 | 374 | 422 | 11.37% |
2 | DDL关键特性 | 84 | 288 | 372 | 22.58% |
3 | DML关键特性 | 257 | 114 | 371 | 69.27% |
4 | PLSQL关键特性 | 70 | 21 | 91 | 76.92% |
5 | 操作符 | 38 | 0 | 38 | 100% |
6 | 数据类型 | 26 | 15 | 41 | 63.41% |
7 | 系统高级包 | 2 | 143 | 145 | 1.3793% |
8 | 系统函数 | 282 | 434 | 716 | 39.38% |
9 | 系统视图 | 1 | 126 | 127 | 0.78% |
| 汇总 | 808 | 1515 | 2323 | 34.78% |
其中操作符的兼容性是100%，其他的兼容性都还有一定的差距。DML兼容性接近70%，PL/SQL的语法兼容性接近80%，从这两个指标上看，应用迁移难度也不算太大，但是想要平替是不大可能的。数据类型的兼容度只有63.41%，这是个比较麻烦的事情。
一级分类 | 二级分类 | 三级分类 | 四级分类 | 5.0.1 | 5.1.0 |
数据类型 | 字符型 | VARCHAR2(size [BYTE | CHAR]) | VARCHAR2(size CHAR) | 不兼容 | 不兼容 |
数据类型 | 字符型 | VARCHAR2(size [BYTE | CHAR]) | VARCHAR2(size BYTE) | 不兼容 | 不兼容 |
数据类型 | 字符型 | LONG | | 不兼容 | 不兼容 |
数据类型 | 字符型 | CHAR [(size [BYTE | CHAR])] | CHAR(size CHAR) | 不兼容 | 不兼容 |
数据类型 | 字符型 | CHAR [(size [BYTE | CHAR])] | CHAR(size BYTE) | 不兼容 | 不兼容 |
数据类型 | 字符型 | NCHAR[(size) [BYTE | CHAR]] | NCHAR(size CHAR) | 不兼容 | 不兼容 |
数据类型 | 字符型 | NCHAR[(size) [BYTE | CHAR]] | NCHAR(size BYTE) | 不兼容 | 不兼容 |
数据类型 | 数值型 | BINARY_FLOAT | 不兼容 | 不兼容 | |
数据类型 | 时间型 | TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE | 不兼容 | 不兼容 | |
数据类型 | JSON类型 | JSON | | 不兼容 | 不兼容 |
数据类型 | 二进制型 | LONG RAW | 不兼容 | 不兼容 | |
数据类型 | 排序/伪列 | ROWID | | 不兼容 | 不兼容 |
数据类型 | 排序/伪列 | UROWID [(size)] | 不兼容 | 不兼容 | |
数据类型 | NCLOB型 | NCLOB | | 不兼容 | 不兼容 |
数据类型 | 二进制文件 | BFILE | | 不兼容 | 不兼容 |
不过幸运的是，这些不兼容的数据类型在国内的应用中使用较少。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的分布式版本。
