明天开始我要开启休假模式，去佛国囊谦玩几天。可能对囊谦大家有点陌生，不过记住这一点，这个被誉为千佛之国的囊谦县，绝对是值得去玩上个把星期的。
昨天好几个朋友留言问数据库迁移友好性的问题，这其实是一个十分复杂度问题，无法在留言中百十来个字就回答清楚，今天就写一写吧。
首先迁移友好性是不是兼容性呢？答案是否定的，兼容性只是迁移友好性的一个纬度而已，并不是全部。
迁移友好性涉及到语法兼容性、数据类型兼容性、操作符兼容性、功能兼组件容性、互访兼容性、编程接口兼容性等兼容性方面的特性。这些都是基础特性，我前几天发的那篇关于OPENGAUSS与ORACLE兼容性分析的文章，大多数指的就是这方面的兼容性。
在与Oracle的兼容性方面，达梦无疑是其中的佼佼者，2016年我们在帮用户迁移一套核心应用的时候，只有wm_concat这个函数没有，后来写了一个，应用程序换了个驱动就能跑起来了。除了达梦之外，好像还没有第二个数据库产品有如此高的Oracle兼容性。Oceanbase的Oracle租户模式在分布式数据库中算是兼容性比较好的了，不过因为分布式数据库的特性，原来的Oracle数据库应用想要用OB平替还比较困难。想要平替的系统，一般来说都是规模较小，数据量较小，用户体验要求一般的系统。在一些大型企业中，这类系统很多，如果迁移时候应用要做较大改动，成本太高，可以选择这种平替的方式。
除此之外，迁移友好性还牵涉到很多其他纬度的特性。比如说我们想要平替某套系统，可能换个驱动，应用就跑起来了，但是SQL的执行效率都很低，无法满足日常使用的需求。这种情况下，兼容性就不能满足要求了。还需要有执行效率的迁移友好性，目标数据库需要和Oracle在执行效率上处于差不多的水平，不仅仅是QUERY，还有DML/DDL/DCL等。只要应用运行于运维日常用得到的地方，其执行效率的友好性都很关键。比如说我们要做一个表分区的分裂操作，目标数据库在功能上虽然是兼容操作的，但是效率是Oracle的几十分之一，那么原本需要1小时，可以在运维窗口完成的操作就无法找到可执行的运维窗口了。
我曾经遇到过某系统，迁移到一个国产数据库上之后，应用系统的核心模块平均慢了30倍，后来花了几个月时间才优化好。这种情况，虽然语法兼容性没问题，但是迁移友好性还是不高的。
迁移工具也是迁移友好性的一部分，是否拥有优秀的迁移工具（自带或者第三方都OK），能够十分方便地将数据和应用迁移过来，也是评价迁移友好性的一个十分重要的维度。哪怕语法兼容性不够好，但是有很好的迁移转换工具，只需要少量的人工介入就能完成迁移，这样的数据库，其兼容性虽然不够好，但是迁移友好性还是不错的。
数据同步工具也是迁移友好性的重要部分，支持便捷的初始化复制和增量同步的数据同步工具是迁移较大型关键系统的十分重要的工具。如果是核心系统，还需要双向同步工具。因为系统肯定要存在一定时间的双平面双轨运行阶段。此时需要确保系统随时可以切回Oracle数据库。
DBLINK的支持对于某些场景来说也是迁移友好性的关键成分，如果核心系统与外部系统关联较多，但是有些系统暂时还无法迁移，那么目标系统与Oracle的互操作性就十分关键了。有DBLINK能力的存在，可以让互操作变得更加简单。
除此之外，运维工具、运维能力、团队的技术积累等也都是迁移友好性的重要组成部分。随着迁移工作的深入，这些能力的重要性会越来越高，这也是我昨天文章最后说的，他们已经选择了某个数据库产品，而且已经迁移了二十多套系统上去了，已经积累了大量的迁移、改造、优化和运维的经验。在进行系统迁移方面，这个目标数据库的迁移友好性肯定 是越来越高了。
今天因为时间关系，就谈这么多吧。明天要开启今年的第一次户外活动，下面的一周多的时间里，我会暂时停止更新。或者偶尔会发一些在囊谦的所见所闻所感吧。
