探讨信创数据库迁移实施策略，涵盖测试验证、实施过程及运维保障，分析迁移难点，展望未来发展方向。
原文标题：信创数据库迁移实施策略探讨
原文作者：牧羊人的方向
冷月清谈：
首先，迁移测试与验证阶段至关重要，需要对现有数据库系统进行全面评估，包括环境摸底、兼容性分析和业务影响分析。在兼容性测试与适配改造方面，需关注SQL语法和数据库对象的兼容性，并进行性能压测与优化验证，为后续的性能优化提供数据支撑。数据迁移测试则需关注全量迁移和增量同步，并设计完善的回退方案，以应对可能出现的迁移失败。
其次，迁移实施阶段包括环境准备、投产准入和数据库迁移实施方案。环境准备涉及数据库资源交付、配置检查以及与运维平台的对接。投产准入则需要完善投产手册、进行SQL规范性检查。数据库迁移实施方案需要明确迁移方式，并进行数据迁移和迁移后检查，确保信创数据库已具备切换条件。
最后，迁移后的运维保障需要建立完善的运维监控体系，实现与现有平台的监控告警与性能指标对接。同时，进行性能优化及调优，并制定备份与容灾策略，定期进行容灾切换演练。此外，还需要及时更新运维手册和应急维护手册，并梳理迁移经验，形成信创数据库迁移改造最佳实践。
文章还指出了信创数据库迁移实施的难点，包括存量数据库应用的差异性、迁移流程无法工具化或平台化以及规范性标准难以量化。并强调了信创数据库迁移改造需要不断打磨，才能真正实现高枕无忧。
怜星夜思：
2、文章提到信创数据库在性能上与传统数据库存在差距，特别是在复杂查询场景下。除了增加硬件资源和优化SQL，还有哪些其他有效的性能优化手段？
3、文章中提到了多种迁移方案，如停机迁移、在线双写、全量+增量等。对于一个拥有50TB数据的大型电商平台，你认为哪种迁移方案是最合适的？为什么？
原文内容
随着各个行业的数据库国产化信创改造逐渐进入深水区，既有的数据库如Oracle、DB2、MySQL等也逐步向自主可控的信创数据库进行迁移和适配改造。在各应用向信创数据库迁移实施过程中，不可避免的会遇到几个痛点问题：
-
首先是信创数据库的语法兼容性和应用适配问题，原有的Oracle等数据库在SQL语法以及数据类型上和信创数据库存在一定的差异，迁移过程中需要应用进行一定的适配改造，有些应用因为历史技术债甚至会有几千个存储过程需要适配改造。针对这一点各数据库厂商也同步开发了数据库对象兼容性改造工具，兼容性能达到80%以上，也在一定程度上解决了兼容性问题。
-
其次是迁移方案的实施难度问题，数据迁移的窗口一是要考虑到停业窗口的压力，另外在异构数据库迁移前后的数据一致性比对和校验，缺乏自动化的工具并且比对效率低。对于一些重要的业务系统需要充分评估SQL和存储过程的改写，甚至涉及到应用的重构，并且需要双发验证后才能完成迁移切换运行，耗时2~3年，实施周期长。
-
最后是迁移到信创数据库前后的性能差异，目前信创数据库与传统Oracle等数据库对比在性能上还是存在着一定的差距的，尤其是在一些复杂的多表关联业务处理场景中。加上由于全栈信创叠加的硬件性能上的退化，信创数据库迁移过程中需要充分测试评估过程中的性能影响，通过叠加硬件资源（比如1:1.5的资源比例）以及优化SQL等方式以满足性能要求。
针对信创数据库迁移实施策略（如上图所示），将从迁移测试评估与验证、迁移中实施以及迁移后的运维保障三个阶段进行展开。
1、信创数据库迁移测试与验证
1）环境摸底
应用在数据库信创改造的时候需要充分评估现有的数据库系统，梳理原数据库类型、部署架构、版本、数据量、表结构、存储过程、触发器、依赖业务系统等，形成数据库画像。通过自定义SQL或脚本的方式采集现有数据库的性能指标数据，得到数据库的资源消耗、TPS/QPS、表对象信息、存储过程和函数的使用情况，对现有系统有个充分的掌握和了解。
2）兼容性分析
针对现有数据库和目标数据库的特性差异，提炼出异构数据库在SQL语法、数据类型、事务隔离级别、字符集支持等层面的差异，并制定适配改造清单，包括语法差异类、功能缺失类、性能差异类和配置差异类，并且标注高风险清单。另外基于数据库厂商提供的迁移评估工具，如GaussDB数据库的UGO，评估信创数据库与原数据库的兼容性差异，并进行数据库对象自动转换等，这个数据库对象自动转换有效率能达到80%以上。
3）业务影响分析
通过梳理业务模块的调用链和上下游访问关系，识别关键业务模块对数据库的依赖关系，明确迁移的优先级和风险点，并针对性的制定分阶段的迁移计划，如先迁移非核心业务模块进行方案验证。
1）语法适配
通过数据库迁移工具改造不兼容的SQL语句，如分页查询、日期函数、字符串隐式转换、一些特殊语法如Oracle数据库的NVL函数等。针对工具无法处理的复杂逻辑（如Oracle的WITH AS子查询嵌套），手动改写并验证功能一致性。
2）对象迁移测试
通过迁移工具对数据库对象进行转换改写，并验证表结构、索引、视图、存储过程、触发器等对象在信创数据库中的兼容性。如校验转换前后的表结构字段是否一致，索引是否丢失、自增序列和约束的定义是否完整。对于存储过程和函数等对象，需要应用在目标数据库中执行，并验证结果是否符合预期。
1）基准测试
基准测试主要对联机业务场景和批量场景（如高并发读写、复杂查询、事务处理等），对比源库与信创目标库的TPS、QPS、响应时间等性能指标，并出具性能测试报告。通过基准测试能够直观的看到数据库迁移前后的性能差异，并通过一些优化措施如增加资源、参数调整或优化SQL的方式来优化，也为后续生产环境信创数据库的资源申请提供数据支撑。
2）参数调优
基于基准测试的结果，以及信创数据库自身产品特性，调整内存相关参数、连接池配置、锁机制等参数。比如动态内存和共享内存的分配、连接池的超时回收策略、锁等待超时时间、临时文件的写入大小等。
数据迁移分为全量迁移和增量迁移，各个数据库厂商也提供迁移工具来实现异构和同构数据库的迁移，迁移过程中的难点是数据的一致性比对、断点续传以及反向同步。
1）全量迁移测试
全量迁移是使用数据库迁移同步工具将全量数据同步到目标端，迁移完成后需要验证数据迁移的一致性和完整性，常用的校验方法包括MD5校验和对比源库与目标库的表数据，或通过COUNT(*)统计行数差异、随机抽取关键字段进行抽样比对等方式。
2）增量同步验证
增量同步是在全量迁移的基础之上，将源库上增量增删改的数据实时同步到目标库，这个是正向同步。另外还需要验证反向同步的能力，将信创库中的变更操作反向同步到源库中，用于后续的业务回退方案。增量同步过程中还需要验证网络异常或同步链路中断后，同步工具是否具备断点续传的能力。同时还有一些特殊的DDL操作，如build索引、truncate分区等，能否完成同步。另外，对于增量同步的表，是要求带主键的，这些在表结构规范设计时候需要注意的地方。
1）回退方案
回退方案是制定迁移失败时的回滚计划，确保数据可快速回退到原表、业务影响可控。一种是在迁移过程中出现问题，此时还在停业窗口中，直接将应用的连接指向源库，可以实现秒级回退。还有一种是业务已经切换到信创库中，此时如果业务上出现不可规避的问题需要回切到源库，则需要用到反向同步的链路，将应用连接指向源库。对于实现交易双发并轨运行的迁移方案，可以在业务并行期提前发现问题，真正在切换时候遇到异常也可以随时回切。
对于双发验证或交易回放验证，是否有必要，是否覆盖到所有待迁移应用等，还是一个颇具争议性的话题。从运维稳定性来看，每个应用都建一套目标库的环境进行交易双发以充分验证信创库的功能和性能，但在实际执行层面是不可行的，面对几百个应用系统的信创迁移改造，将耗费巨大的时间、资源和人力成本。因此最好的策略是按照应用重要程度进行分级，对于一些核心业务和关键业务渠道类的系统，通过交易双发或回放，以验证性能。
1）交易双发
核心类业务系统在生产环境单独部署信创类系统，交易同时发送到现有系统和信创系统运行，通过对比结果验证一致性。交易双发可以充分验证迁移前后业务处理逻辑上上数据一致性的差异，对于涉及到应用重构类的，比如核心业务系统改造，这种方式是最适合的。
2）交易回放
重要类业务系统采集生产的报文数据在预生产环境进行流量回放，验证迁移后的性能。交易回放在执行层面相对容易些，通过生产真实的交易报文数据，在准生产环境使用Jmeter等工具进行流量回放，主要是对比源库的性能和兼容性。当然也需要额外的资源和人力投入部署环境以及回放验证。
3）SQL回放
通过录制生产的SQL在准生产环境回放，以验证SQL的兼容性和性能情况。由于运行环境的差异以及绑定本地变量等因素，实际SQL回放的效果会打些折扣。而且又涉及到将原数据库的SQL语句转换为信创数据库兼容的SQL语句，无疑增加了回放的准确性和难度。
以下是三种方式的优缺点对比
2、信创数据库迁移实施
1）环境部署
数据库资源交付包括数据库环境、应用用户及授权、网络访问授权、迁移工具就绪等。应用按照性能测试的结果以及现有数据库资源使用情况，评估申请信创数据库服务器资源，并提交环境部署，包括部署的架构、创建的库以及用户和授权，同步的会部署配套的迁移工具、开通必要的网络访问权限。
2）配置检查
环境部署交付后，对数据库环境和应用环境的配置和参数进行，如用户名及权限、URL连接串等。一般会有一个环境检查清单，执行脚本逐一核对清单的检查结果，确保无误。
3）运维平台
信创数据库上线前需要和必要的运维基础平台进行对接，包括监控、SQL安全查询工具、自动化部署平台、数据库运维平台等。
1）手册完善
作为投产变更评审的必要材料，需要包括性能测试报告、投产手册和迁移手册、应急回退方案等。性能测试报告中包括主要高频交易接口和批次的性能对比情况、投产手册和迁移手册详细列出迁移步骤和操作步骤、回退方案中需明确回退的触发条件和回退影响等内容。
2）SQL规范性检查
应用SQL代码已接入持续集成环境，根据既定的规则（如索引是否合理、是否全表扫描等）自动扫描SQL语法的规范性，并提供SQL检查报告。同时对不符合规范的SQL进行拦截并标注，让开发团队进行优化。
1）迁移方案
明确迁移方式，比如停业迁移、通过全量+增量同步完成一次性切换等，如果涉及到停业的还需要报相关监管机构进行报备业务影响。
|
方案类型
|
适用场景
|
优缺点分析
|
|---|---|---|
|
停机迁移
|
小型业务系统（<1TB）
|
RTO≤2小时，需业务停服
|
|
在线双写
|
核心交易系统
|
数据最终一致，架构改造成本高
|
|
全量+增量
|
超大库（>10TB）
|
需持续同步，切换窗口短
|
2）迁移实施
根据制定的迁移方案实施数据迁移，如使用全量迁移+增量同步的方式，利用迁移同步工具进行存量数据同步，再进行增量数据的同步，并进行数据一致性校验。
3）迁移后检查
数据迁移完成后，需要检查应用索引状态、统计信息、自增序列、数据库运行状态等，并修复失效索引、更新全量表的统计信息、将目标库中的自增序列值对齐，确保信创数据库已经具备切换条件。
1）应用配置调整
应用侧也需要进行相应的配置调整，将应用URL连接指向信创数据库，并且使用推荐的驱动以及调整连接池和开发框架对应的配置。
2）灰度切换
在业务切换过程中，首先迁移并验证非核心业务模块，验证无误后再覆盖到核心的业务功能模块。
3）端到端验证
迁移到信创数据库，执行关键业务流程进行技术和业务验证，确保功能正常
4）异常回退
业务或技术验证异常时，根据回退方案快速回退到原有的业务，保证业务的连续性。
1）实时监控
在迁移过程中的实时监控迁移的进度情况、CPU和内存等资源使用率以及数据库主备延迟等指标并配置告警策略，出现异常时及时介入应急。
2）故障应急
针对迁移过程中的异常如迁移后校验数据不一致、迁移同步任务中断等，快速定位原因并修复。实际实施过程中要根据具体情况针对性的分析，如数据乱码导致同步数据丢失，则使用工具修复差异数据。
3、信创数据库迁移后运维保障
1）监控对接
信创数据库基于自身数据库运维平台的管理能力，实现与现有平台的监控告警与性能指标对接，并对外提供API接口和SQL接口能力，实现SQL查询工具和业务运行指标监控等功能。
2）基础平台对接
与现有的运维基础平台对接，将信创数据库的拓扑和实例信息同步到配置库CMDB；同时对接日志平台，实现数据库运行日志、慢SQL日志和审计日志的保存和搜索；对接容灾切换平台，实现应用层的一键切换功能；另外按照备份恢复策略，将数据库中数据备份到集中备份用于数据的灾难恢复。
3）迁移后的运维保障支持
重要业务系统T+n日现场运维保障支持，并每日输出运行日报，包含关键指标（如TPS、QPS）、异常事件（如慢SQL）及优化建议。
1）性能对比优化
采集迁移前后的数据库性能指标数据，对比前后的TPS/QPS、响应实际等关键指标的差异，并形成对比报告。同时分析对应的慢SQL语句，并给出针对性的优化建议进行整改。
2）资源扩容
根据业务增长和系统资源使用情况，观察业务高峰期和CPU峰值时间点的运行情况，适时调整存储、内存以及计算资源。
3）深度巡检
对迁移后的应用和数据库进行深度巡检，分析数据库AWR报告并针对性调优，如应用gc问题、数据库参数调整等。
1）备份恢复策略
各应用制定定期备份恢复的策略，由DBA根据策略配置备份任务，并根据业务需要或数据恢复需求恢复数据，包括PITR恢复和异集群恢复等。
2）容灾演练
根据切换演练安排定期进行容灾切换演练，包括主备切换、站点级切换等，以充分验证系统架构的高可用性，确保RPO和RTO满足业务连续性要求。
1）运维知识库更新
信创数据库迁移完成后，需要及时的更新运维手册和应急维护手册，记录常见的问题、告警处理及应急措施。
2）迁移经验分享
梳理迁移经验，形成信创数据库迁移改造最佳实践供后续项目参考。组织迁移复盘会议，分析成功与失败案例，总结教训。将一些通用的配置定义到开发和运维规范中，便于后续的应用按照规范的配置实施。
4、信创数据库迁移实施的难点
上文介绍了信创数据库实施层面的策略，给出了迁移测试与评估、迁移实施过程和迁移后运维保障相关的具体事项。但在实际的数据库迁移实施层面尚有许多难点难以落实：
-
存量数据库应用的差异性：由于存量应用在使用不同传统数据库时过于依赖数据库自身的能力，比如大量使用存储过程、复杂关联查询等，导致在迁移改造过程中，仅依靠信创数据库自身的能力是无法满足应用平滑迁移的，应用相对应的也需要进行适配改造。为此，需要对全量的应用进行个性化评估分析，梳理出迁移改造项，增加了迁移的成本和工作量，也无法形成一套标准化的迁移模板和流程。
-
迁移流程无法工具化或平台化，形成一套标准的迁移工艺。了解到某头部股份制银行在一个月时间内完成了上百套Oracle数据库的信创替换，如果不借助于标准化的平台工具是无法实现的。上述的工作细项通过流程化，有些其实是可以串联起来的，比如迁移前的数据库对象评估和转换、SQL兼容性分析与转换、SQL审核、性能测试比对、流量回放等，并且平台兼容各类信创数据库的能力，每个环节有输入有产出物。不过信创数据库迁移只是未来2~3年阶段性的工作，看这个投入产出比是否值得了。
-
规范性标准难以量化：比如数据库迁移方案是停业全量还是全量+增量，这个由应用自己去决策，而双发验证似乎没有严格的标准，达到什么标准必须执行，对运维来说似乎稳健起见每个应用都至少交易双发，但是对项目组来说仅仅是内部非重要系统，过于教条化了，最后还是一拍脑袋决定，然后为自己的决定负责。
实际上，未来信创数据库的改造还有很长一段路，尤其是一个新的数据库类型的引入，不经过一两年的时间打磨，从迁移流程到运维体系一整套流程打通，是无法高枕无忧的。