目前使用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虽然用得不是很多，不过我还是云南idc服务商见过一些的，一些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的分布式版本。