春节放假前完成了《凿墙三部曲》，分别介绍了OceanBase、GaussDB和TDSQL三大分布式数据库。
三部曲更多是从产品角度宏观感受了主流分布式数据库的体系架构，对实战而言，知识和经验都不够。
学以致用才是王道，今天的凿墙实战系列先从OMA这个工具讲起。
磨刀不费砍柴工
买房装修，墙不能随便凿，要先看看户型图知道哪儿是承重墙，然后再下手，潭主凿墙（去IOE）也一样。
OceanBase提供了一个叫OMA（OceanBase Migration Assessment）的工具，用于兼容性评估和性能评估。
有了OMA，可以快速评估数据库迁移的工作量和风险，看看到底有多少“坑”，甭管坑大坑小，坑深坑浅，正式开工前都得填平。
虽说目前很多技术问题都有了相对比较标准和成熟的解决方案，但迁移评估与用户环境紧密相连，都是Case by Case的非标。
迁移评估也是整个项目最开始，最重要的一环，这个环节做扎实了，后面就能运筹帷幄。
没有好捏的软柿子
厂商售前讲产品，王婆卖瓜，自卖自夸。但真落到具体项目上，其实有一大堆的前提条件，其中最大的难点就在于应用改造。
而对于分布式迁移改造，不同的用户，诉求不同。
对于关键系统下迁，主要方式分两类：
平切换库
应用架构不做大的改动，只在数据库层面完成分布式数据库对传统集中式数据库的替换，项目通常由DBA负责牵头。
过程中最重要的技术点在于分布式数据库对于源端数据库的兼容性，兼容性越高，应用改造越少，可行性越大。
但可行性与否，全看用户源端的应用和数据库使用情况，完全是个性化的。
该方式看似简单，实则暗礁重重。
系统重构
兼容性之外，用户现有应用架构是另一个重要因素。
如果应用架构较陈旧，是否跟数据库一并配套迁移改造？如果一起做分布式改造，可能还会涉及企业架构改造，牵一发动全身。
当然也可以先换库，再做应用的分布式改造，这要看用户自己的策略。
此外，对于使用封闭技术栈的传统核心应用，这种迁移项目可能会演变成新核心上线，性质也就变了。
如果平切换库是个IT基础设施的项目，那系统重构通常就成了应用研发主导的大工程。
系统重构的项目周期，成本和风险都比平切换库高很多，同时新架构的应用和运维，对于现有组织也是很大的技术挑战。
收益与风险并行，该方式属于典型的先负重前行，再轻装上阵。
不过，系统重构项目也有其好处，迁移测试和系统割接更平滑可控，麻烦的是战线过长。
I/O搭配，干活不累
大厂在保险圈各有战绩，听闻OceanBase拿下了中国人寿，而TDSQL杀入中国太保。
潭主之前对行业案例也做了一些简单的调研，国寿和太保都是Oracle的InstallBase，而TK作为曾经的IBM InstallBase，虽说技术上可参照性不强，但操盘思路可以借鉴一二。
对TK来说，DB2比Oracle更核心，所以需要同时进行兼容性评估。
目前，OMA除了MySQL和PostgreSQL外，对主流商业数据库支持如下：
Oracle：11g/12c/18c/19c DB2：v10.1/10.5/11.1/11.5
接下来，从实战的角度看看OceanBase到底能扛多少事。
OceanBase对Oracle的兼容性评估
对OceanBase来说，去O是他的基因，业界也认可其对Oracle的兼容能力。
所以OMA对Oracle的支持做的最完善，可以直连Oracle进行评估，并通过扫描V$SQL视图确认语法兼容性。
对Oracle的评估分成两类：
数据库对象评估：
数据库SQL或PL语句评估：
上图是一个年金投资相关系统的Oracle数据库，看上去评估结果还不错，但换个Schema就没那么乐观了，见下图：
评估的兼容率只有77.96%，几个嵌套表和触发器都涉及业务改造。
对于OMA-30002，虽然数量156，但仔细看了都是有关创建索引的SQL语法问题，不过厂商说是OMA的一个Bug，在OMS迁移的时候会自动解决。
OMA工具可以快速识别出简单问题，但它是一辅助工具，有不少的局限性。
最终每个问题项都需要人工介入做分析判断，如OMA-30215这个加解密问题，就需要等到用户调研时才能判别。
OceanBase对DB2的兼容性评估
DB2太小众，导致OceanBase的DB2迁移案例很少。
前期跟厂商交流过一个银行案例，结果引出了DB2的Oracle兼容模式，不得不感叹Oracle的强大，彼此都跟Oracle兼容，从而间接实现了OceanBase对DB2的兼容。
目前，OceanBase仅支持db2look导出脚本的静态兼容性评估，如下图：
相比Oracle的兼容率，DB2差了一大截，普遍不足90%。
潭主看到DB2的评估报告后，心里哇凉，感觉满眼都是工作量。
目前，DB2的工作基本靠人工，评估迁移工作量的方式就是看代码量。
如上图的OMA-30213，DB2用了物化视图，但OceanBase暂不支持，所以用到这个功能的应用就要改，等后续版本这种事要看缘分。
再如OMA-30503，看上去876的数量挺大，有点吓人，但其实都是基于时间的范围分区一个问题。
举个例子，比如DB2中按年定义分区，则2021-01-01到2021-12-31的数据都应落在2021年的数据分区中，到了OceanBase，不支持包含区间内末位值，也就是2021-12-31的数据落到下一个2022年。
解决方案也简单，批量修改分区表的DDL即可，将分区定义改为2021-01-01到2022-01-01，这样2021-12-31的数据就还是落在2021年分区中。
研发投入和对DB2的熟悉程度和直接决定了兼容性评估的实际效果，像DB2 Federation联邦数据，类似Oracle的DBLink功能，都没有包括在内，工具看到的是二维的，而系统迁移至少是三维的。
当然，也未必是看不到，而是怕都展现出来，那可怜的兼容性直接也把用户吓退，那还怎么做生意呢。
这事儿告诉我们一个事实，做厂商要敢于承诺！
OMA的小甜点
安装部署不复杂，支持Web页面和命令行。
MA除了兼容性评估，还能做性能评估。
评估报告分为详细报告（index.html）和评估简报（basic.html）。
兼容性才是高门槛
从产品商业化情况看，虽然OceanBase对Oracle的兼容性做得比较完善，但对DB2的支持相对是很滞后的。
现实中使用DB2的大多是IBM的重度用户，但DB2相比Oracle的市场占有率不值一提，而且像银行这样的DB2用户，几乎选择的都是系统重构的迁移方案。
都说去Oracle难，其实去DB2更难，被Total Solution捆绑着的小众才是真正的高门槛，其底层逻辑在于商业效率，而非技术。
目前TK手握IBM DB2、Informix和AS/400三大冷门。没有对比就没有伤害，别人只凿Oracle一面墙，而我们要凿的墙不仅多，还都是承重墙。
下一战，华为UGO
最初，是想借评估工具找找感觉，但计划赶不上变化，虽说对OMA有了认知，但工作推动效果甚微、远不及预期。
接下来，打算调整策略，等着看华为UGO的表现吧，待续。
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
