从一款工具谈异构迁移评估那些事

发布时间：2025-11-04 14:30:32 来源：云智核 作者：IT科技类资讯

近期关注到云和恩墨发布的从款一款工具-SCA，它可以协助用户评估异构数据库迁移。工具构迁估那近些年个人参与了不少异构数据库迁移，谈异自己也曾有想法做个工具用来评估异构迁移的移评兼容性及性能等问题。这一工具也给出一种实现，从款可以对很多面临数据库迁移的工具构迁估那用户带来现实参考意义。本文就尝试从此工具的谈异功能着手，谈谈异构数据库迁移的移评那些事。

1. SCA 产品功能说明

让我们先来看看发布的从款此款工具的功能，下面信息取自部分 SCA 工具官网描述。工具构迁估那SCA 全称 SQL Compatible Analysis，谈异是移评一款异构数据库迁移前的 SQL 兼容和性能评估工具。可用于异构数据迁移前的从款兼容性评估，评估源数据库中的工具构迁估那实际业务 SQL 在目标库中是否存在语法问题，以及评估两款异构数据库中的谈异 SQL 实际执行的性能差异。目前此工具支持五种源端数据库，包括：Oracle、MySQL、DB2、PostgreSQL、源码库Informix、SQL Server。此工具执行分为四个步骤，也包含很多执行选项。简单整理如下：

这里我们重点看看其输出报告，报告采用网页或EXCEL文件的格式，内部包含了丰富的信息。下面逐一说明下：❖数据库画像这部分通过扫描源库，收集到源数据库基本信息、性能、对象、SQL等各类信息。在基本信息部分，又包括有主机资源层面信息(CPU、MEM、NET)、数据库信息(版本、角色、架构、归档状态、字符集)。

在性能部分，则包括有多维度数据库性能指标，如 Oracle 数据库就包括有 DB time、CPU time、连接数、TPS、QPS、Redo Size、逻辑读，物理读等。云服务器

在对象部分，则包括各对象类型统计、非标/保留对象列表、大对象统计以及各对象明细的统计信息。

这部分通过对比源库与目标库的兼容能力，分析出对象层面的兼容情况，并分类展示。在展示中按照用户名、对象类型、状态进行汇总，展示相关分类的对象总数以及兼容情况。针对不兼容的对象，就需要考虑在真正迁移中进行修改。

这部分通过对比源库与目标库的SQL兼容情况，评估给出SQL兼容(直接兼容、改写兼容)及不兼容的情况。展示中按照用户名、程序名、模块名汇总，展示系统中采集到的所有 SQL，以及这些 SQL 在目标库支持情况。这些信息对于后续评估改造的工作量评估，有非常直观的指导意义。企商汇

这部分内容根据扫描后的结果，结合系统内置的改写规则，给出该条规则的触发情况，包括该规则在 SQL 中的命中数量及为规则匹配的 SQL 数量。

这部分则是通过复杂度评估标准，判断出复杂 SQL 的分布情况。这些复杂的 SQL 也是在迁移过后需要重点关注性能问题，这样可以有效避免性能问题可能导致的业务故障。目前复杂度的评判标准包括有表关联的数量、Connect By语法使用、自定义函数数量、函数执行耗时。针对每条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 工具做了一个很好的尝试，大大方便了用户的迁移评估工作，有效地降低了迁移成本。国内有很多厂商也有类似的实现，通过独立的小工具完成此类评估。从产品角度来讲，也是一个不错的“引流”产品，并吸引用户最终选择自家数据库。在这里也希望各厂商能够更加关注这一能力的构建，加速用户落地实践。

相关文章