为响应公司拥抱云原生去Oracle战略方向，从今年7月份开始，我们已经开始了各种调研。
先聊聊待迁移的系统
我们拿公司内部核心营销系统（下称“营销云”）作为试点，营销云最早要追溯到2014年，当年公司购买了Oracle的Siebel系统，
基于Siebel开发了配套的营销系统，囊括公司销售渠道，销售订单等等功能。这是营销云的前身。因为Siebel本身比较重量级，每次营销云有功能扩展都需要动到Siebel，
所以后面营销云逐步改造脱离Siebel，直到2019年完成全部功能脱离，但是用的还是Siebel的数据库。目前现状仍然是单体应用。
随着业务的发展，目前营销云已经有上千个页面。业务功能复杂，与集团其他应用系统有深度的集成。这大大提高了我们更换数据库的难度。
系统是以SAAS的形式为全国各地经销商服务。为了不影响业务，我们一开始定的基调是，不能大范围修改代码以及原有sql语句。
一开始我们找到了PolarDb，polarDb可以兼容oracle语法。无奈我们在做调研验证的时候，卡在了数据迁移这步。刚好这时我们又找到了OceanBase，由此开始了
OceanBase的尝试。
兼容性验证
OceanBase号称可以兼容90%以上Oracle常用语法以及存储过程等等，从Oracle迁移到OB可以无缝或少量修改即可。这正好满足我们的要求，我们马上开始了验证阶段。
我们首先使用了OB团队提供的工具进行Oracle版本兼容性的校验，校验结果是100%兼容。
数据迁移验证
我们马上进行了数据迁移的验证。为了模拟真实的情况，我们直接拿生产环境的Oracle库来迁移。去除Oracle本身的日志，整个库的数据量大小是20-30G，涉及数据库对象467个（表+视图）
数据怎么迁移，我们遇到三个难点。
1、营销云应用以及Oracle都部署在广州的私有云，OB那时在华南还没开站点，我们不希望应用在广州，库在华东
2、我们服务不能停太久，必须要尽可能缩短迁移时间，留足够时间验证生产问题
3、如何从私有云Oracle传输到OB。
我们的解决方案：
经过跟OB团队的深入交流，他们把原计划在12月在华南开站的工作提前到9月来做了。所以接下来是数据传输的问题了。
我们首先从阿里云上申请一台服务器安装跟生产环境同版本的Oracle, 从生产环境Oracle导出数据，通过拉专线的方式把数据传输到阿里云服务器，再把数据导入到服务器上的Oracle里面。
最后通过OB提供的OMS工具迁移阿里云Oracle的数据至OB。整个迁移过程耗时在3-4小时，这个是我们能接受的。
OMS工具迁移分两步，先迁移结构，再迁移数据。在迁移结构的时候，遇到个别表结构校验的警告信息，我们忽略继续迁移，但没有对后续数据迁移造成影响。
迁移后应用验证
到此，数据库已成功迁移至OB。接下来是营销云应用的改造。我们的改造基本上就是引入OB的jdbc驱动包，以及修改数据库连接。
抽取了一个相对复杂的业务功能做验证。主要验证 ：
1、sql语法兼容性
2、查询耗时
得出结论：
1、sql语法支持绝大部分，包括常用的Oracle函数。
2、性能问题，开始的时候明显感觉比原来用Oracle的时候响应慢了不少。个别语句直接报查询超时。经OB团队的协助，定位出我们的表没有在关键字段创建索引，把索引建好后查询响应跟原Oracle相当。在得知这个问题之后，笔者在OB后台拉出所有慢SQL，都做了一遍索引优化。
这里抛个问题，原Oracle相同的表也是没有建索引的，但在用Oracle的时候没有表现出性能问题。后来笔者在Oracle上也建上相同的索引，Oracle的查询性能再次提高，但是总体差别不大。（本来就已经是几十毫秒耗时）
后续
阵痛了半个月之后，目前营销云已经在稳定运行。
笔者在日常操作OB的过程中，总结了如下几点OB需要优化的地方
1、merge语句的using 子语句只支持单表，不支持复杂查询。
2、dblink暂时还不支持 OB连Oracle（OB团队说3.0版本会支持）
3、批量提交的数据量大小目前限制死100M。原来用Oracle可以正常执行的语句，例如merge, insert select ，create table select，等等语句，遇到数据量大的时候会直接报错
4、管理后台做的略为粗糙了一点，例如在查看慢SQL的时候，个别sql比较长，页面直接就截断了，无法得知完整sql语句。截止到笔者写这篇文章的时候，这问题还没修复
我们此次迁移算是公司的先头部队，后续其他系统可能也会做迁移，届时会重点关注dblink的模块。因为我们几个核心系统大量用到dblink。
