最近涉及信创的事情比较多，很多朋友也和我讨论信创数据库改造时应该注意一些什么问题。实际上最终涉及的问题包含两方面，一方面是选型，一方面是迁移。从Oracle向国产、开源数据库做数据迁移目前实际上是比较成熟的，有大量的工具可用。当然对于大数据量的业务迁移还是有一些工作量的，不过都还是可以克服。
实际上目前我们遇到的第一大难题就是选择的问题，国产数据库太多了，怎么选都眼花。实际上可能很多数据库选型都有些走偏，大家过多的去关注TPCC、TPCH这些很可能对实际选型没太大影响的测试。每个数据库厂商都会对这些基准测试做很好的优化，因此从这些测试中实际上也获取不到很多有价值的数据。
实际上选择数据库的时候，我们还是要从迁移成本、使用成本、复杂业务支撑能力等方面入手。实际上最需要测试的第一方面就是与Oracle的兼容性，因为我们大多数都是要把系统从Oracle上迁移下来，与Oracle的兼容性越好，就意味着迁移成本越低。兼容性测试只要集中在一些SQL的特殊语法、窗口/统计函数、常用函数、SEQUENCE、PL/SQL存储过程等方面。
除了兼容性外，第二重要的因素是高可用，高可用是确保业务SLA的关键，高可用切换方案是否能够满足业务SLA的需求，切换是否能够自动化，切换时是否顺畅，这些都是需要认真测试的。而且这种测试往往需要带一定负载，甚至带高负载进行。
第三个重要特性是备份与恢复，虽然所有数据库都支持备份与恢复，不过其能力差异很大。备份恢复操作是否顺畅，与磁带库、虚拟带库之间的兼容性，与常用备份工具平台的兼容性等都是需要考虑的因素。另外就是备份恢复的粒度，是否支持表级甚至块级恢复也是十分关键的考虑因素。
可靠性测试是不容易做的，这需要做耐力测试，要想在有限的时间内从耐力测试中发现问题，对于测试用例有极高的要求。
除此之外，我们还要十分关注一些CBO优化器方面的问题。原生的PG数据库与Oracle在HASH JOIN等高级表连接上面是有一些差异的。虽然说PG也支持HASH JOIN，不过在有些场景下，PG的HASH JOIN支持并不完善。比如下面的场景：
我们创建两张表，执行一条带or的表连接条件的查询，就会发现执行计划并没有走HASH JOIN，而是使用了NESTED LOOP。
而如果我们把Or的表连接条件去掉，则又走回了HASH JOIN这种性能比较好的连接方式。当表的数据量很大时这两种连接的性能差异很大。
我们把这个测试用例用到基于PG的一些国产数据库上，得到的结果是类似的。比如在openGauss v3上，我们获得了相类似的结果。
如果我们的应用中有这样的SQL，那么怎么办呢？只能改写，将这些SQL拆分或者用UNION语句来改写。我手头正好有一套OB4.0的环境，测试一下，执行计划是这样的：
OB在CBO优化器里自动对这样的SQL进行了改写，在执行计划里看到了UNION的操作。
类似这样的问题在国产数据库中还有很多，因此在做选择的时候，最好能够把自己的ERP,SCM，仓储，财务等系统中相对比较复杂，数据量较大的SQL抽取一些出来，在待选产品上做一些测试，可能能够比对出更有价值的数据出来。
