近期关注到云和恩墨发布的一款工具-SCA，它可以协助用户评估异构数据库迁移。近些年个人参与了不少异构数据库迁移，自己也曾有想法做个工具用来评估异构迁移的兼容性及性能等问题。这一工具也给出一种实现，可以对很多面临数据库迁移的用户带来现实参考意义。本文就尝试从此工具的功能着手，谈谈异构数据库迁移的那些事。
1. SCA 产品功能说明
（1）功能概述
让我们先来看看发布的此款工具的功能，下面信息取自部分 SCA 工具官网描述。SCA 全称 SQL Compatible Analysis，是一款异构数据库迁移前的 SQL 兼容和性能评估工具。可用于异构数据迁移前的兼容性评估，评估源数据库中的实际业务 SQL 在目标库中是否存在语法问题，以及评估两款异构数据库中的 SQL 实际执行的性能差异。目前此工具支持五种源端数据库，包括：Oracle、MySQL、DB2、PostgreSQL、Informix、SQL Server。此工具执行分为四个步骤，也包含很多执行选项。简单整理如下：
（2）输出解读
这里我们重点看看其输出报告，报告采用网页或EXCEL文件的格式，内部包含了丰富的信息。下面逐一说明下：❖数据库画像这部分通过扫描源库，收集到源数据库基本信息、性能、对象、SQL等各类信息。在基本信息部分，又包括有主机资源层面信息(CPU、MEM、NET)、数据库信息(版本、角色、架构、归档状态、字符集)。
在性能部分，则包括有多维度数据库性能指标，如 Oracle 数据库就包括有 DB time、CPU time、连接数、TPS、QPS、Redo Size、逻辑读，物理读等。
在对象部分，则包括各对象类型统计、非标/保留对象列表、大对象统计以及各对象明细的统计信息。
对象兼容度汇总
这部分通过对比源库与目标库的兼容能力，分析出对象层面的兼容情况，并分类展示。在展示中按照用户名、对象类型、状态进行汇总，展示相关分类的对象总数以及兼容情况。针对不兼容的对象，就需要考虑在真正迁移中进行修改。
SQL 兼容度汇总
这部分通过对比源库与目标库的SQL兼容情况，评估给出SQL兼容(直接兼容、改写兼容)及不兼容的情况。展示中按照用户名、程序名、模块名汇总，展示系统中采集到的所有 SQL，以及这些 SQL 在目标库支持情况。这些信息对于后续评估改造的工作量评估，有非常直观的指导意义。
SQL 改写规则
这部分内容根据扫描后的结果，结合系统内置的改写规则，给出该条规则的触发情况，包括该规则在 SQL 中的命中数量及为规则匹配的 SQL 数量。
SQL 复杂度分布
这部分则是通过复杂度评估标准，判断出复杂 SQL 的分布情况。这些复杂的 SQL 也是在迁移过后需要重点关注性能问题，这样可以有效避免性能问题可能导致的业务故障。目前复杂度的评判标准包括有表关联的数量、Connect By语法使用、自定义函数数量、函数执行耗时。针对每条SQL的复杂度都会按照上述标准进行汇总评估，给出SQL复杂度。
SQL 性能对比
这部分是在结构、数据迁移完毕后，真实执行SQL，采集源端和目标端的执行性能进行比较。按照执行性能的总体情况及分列情况的展示。其中总体部分，可以简单评估下迁移完成后在目标库的整体运行状态，包括性能有提升的SQL比例、性能下降的SQL比例、不支持的SQL比例等。
在分列的部分则可以按照工作负载、SQL、超时维度展示具体的TOP SQL的情况，包括此SQL的性能变化情况及对整体负载的影响情况。这一能力很赞，可以筛选出影响大的SQL，优先优化解决。
此外针对每条SQL可以详细展开，包括SQL文本、绑定变量、执行计划、执行详情、关联对象、统计信息等。
2. 异构迁移评估的若干难点
SCA，这一工具给我们异构数据库迁移的一个很好的工程化实践范例。那这一工具的实现功能上，也反映出迁移评估的若干难点问题。这些问题也正是困扰着用户如何快速替换一款数据库。这些难点问题，简单整理如下：
（1）全面详实地收集源库各类信息
在我们谈异构迁移之前，首要问题就是如何全面详实地收集源端库的各类信息。SCA 工具帮我们收集了如硬件、操作系统、数据库基本信息、对象、SQL类的信息，但从迁移角度来说这些信息还是不够的。之前笔者也曾经写过一个模板，方便用收集源库的信息，具体参见“调研模板”，这也是结合之前工作经历整理所得。但在实际使用中，收集效果往往大打折扣，原因一方面是因为很多信息用户也不清楚，另一方面也是觉得填写繁琐、不愿意花精力填写。但按照以往的经验，这个过程是值得的。本人就曾经遇到多次因为收集信息不完整导致迁移方案失败，甚至到上线之前才知悉，再选择其他方案代价很大。那么简化这一过程的最好方式就是工具化、自动化，类似 SCA 这样的工具能够帮助用户极大简化这一过程。
（2）对目标数据库能力有充分理解
异构数据库迁移，一方面要尽量详实地了解源数据库的情况，另一方面也要对目标数据库的能力有个全面理解。特别是目标库如果采用的新架构、新技术等，与源数据库通常不能简单一一比对。例如之前源数据库采用集中式架构、目标数据库采用分布式架构，那么原有很多源库的能力就不能简单照搬过来，需要新的做法、甚至是在应用、架构层面做更多的考虑。
（3）正确理解“兼容”的概念
很多用户理解兼容，是一个很美好的状态。在应用不需要任何修改的情况下，就可以全面照搬过来。其实兼容是个很复杂的事，本人之前也写过一篇关于兼容性的文章，参考“Oracle兼容性面面观”。仅就 SQL 的兼容性问题，就需要一方面考虑语法、语义的兼容情况，一方面考虑不同的兼容方式(完全兼容、等价兼容)，还要考虑如性能表现、异常处理等情况。SCA 工具这方面做的不错，给出了不同兼容的统计及性能数据的对比。
（4）复杂对象和语句的迁移问题
很难有两个数据库是可以完美兼容适配的，针对源库那些复杂对象和语句，如不能在目标库上有对等实现也要给出必要的解决路径。从对象来看，如库内计算(包、存储过程、触发器、函数)、视图(含物化视图)、序列(自增类型)、特殊字段(大对象、JSON)等，是需要考虑目标库的实现机理和能力及是否有其他替代方案。例如很多存储过程，就可以转化为外置过程来解决。从SQL语句来看，复杂SQL的处理是容易出现问题的，SCA 工具也意识到这点给出了专项的统计。即使在目标库可以实现，也建议尽量简化语句逻辑，避免潜在的执行风险。
（5）从“仿真”角度评估迁移结果
如何真实地还原源库的工作负载，在目标库上进行仿真重演，进而评估迁移后的结果，这是最为准确的评估。这里不仅是单一对象、语句的迁移评估，而是真实的、带有业务负载的、有数据质量差异(甚至是错误数据)下的测试结果，这样才能真实反映出评估后的结果。很多时候，单一对象或语句都是可以很“完美”的跑出结果，但是放在真实环境下就会出现各种问题。其结果的反馈，可以通过与源库的结果对比来进行评估。有的时候往往是一些很细节的地方非常容易出现问题，例如空值的处理、精度问题、时区问题等。
写在最后
随着国产化替换浪潮涌现，正有越来越多的企业在计划或正在进行数据库替换工作。异构数据库迁移评估，成为用户实现替换的必备条件之一，也是困扰很多用户的一点。SCA 工具做了一个很好的尝试，大大方便了用户的迁移评估工作，有效地降低了迁移成本。国内有很多厂商也有类似的实现，通过独立的小工具完成此类评估。从产品角度来讲，也是一个不错的“引流”产品，并吸引用户最终选择自家数据库。在这里也希望各厂商能够更加关注这一能力的构建，加速用户落地实践。
