为帮助金融机构做好分布式数据库产品的选型，推动分布式数据库产品在金融领域的稳妥应用，金篆GoldenDB在北京金融科技产业联盟的指导下编写《GoldenDB分布式事务型数据库金融应用指南》。《指南》深入探讨了如何从应用规划、应用开发、数据迁移等关键环节，将金篆GoldenDB引入金融机构的IT系统中；在数据安全方面介绍了数据加密、访问控制等功能，在性能调优部分提供了完整的优化策略。
上期为大家讲解了基于金篆GoldenDB数据库迁移前，如何完成调研评估。本期是系列文章的第11期，将深入介绍基于前期的调研信息，如何制定数据迁移方案。
选择整体迁移方案
基于全量同步的割接方案，无需反向同步
对于允许离线迁移的业务系统，建议采用全量迁移方案。在全量割接期间，Oracle源库需停止数据更新，金篆GoldenDB迁移工具Sloth采用全量迁移模式，进行全量数据采集、回放以及全行比对，最后阶段采取各表count计算，关键表进行sum计算的核验方式，确保源库目标库数据完全一致。
基于全量+增量+比对+反向同步方案
针对需要反向同步到源库来进行兜底的应用场景，建议采用此方案。
明确数据迁移时长
数据迁移总时长要保证至少两次全量+增量迁移+追平所需的时间，在此时间基础上越短越好，一是缩短对业务的影响，二是迁移时间过长会因各类异常事件可能导致迁移计划失败。
针对金融联机交易系统停机窗口十分紧张，因此，实际迁移均采用全量+增量的方式进行数据迁移，全量迁移通过对历史数据进行迁移，可以提前以离线（备机）的方式在不影响联机交易的情况下进行迁移，之后通过数据同步工具搭建正向同步通道，实时增量复制源端数据并同步至目标库，期间对联机交易无影响，待新系统割接上线当晚，完成最后增量数据同步后，经过必要的数据校验环境，可以在尽量小的停机窗口内进行新旧系统数据库的切换，从而完成系统的上线。
确定相关软件配合方案
1. 申请足够的数据迁移工具权限，包括不限于端到端的网络权限以及源端数据库的访问权限。
2. 源端生产库的配置修改申请。由于金篆GoldenDB迁移工具基于归档日志进行增量数据同步，为了更好地实现数据迁移，需修改源库的归档周期到合适的范围，并设置归档最大保存时间（归档保存时间宜大于总迁移时长）。
3. 数据库数据迁移期间需要申请客户DBA配合割接，需清晰的描述：时间、步骤、动作内容，以及注意事项。比如停止生产库日常运维操作（表空间和表或表分区等DDL操作）；何时启停ADG备库；是停ADG同步还是停止回放；是否需要检查SCN或者查杀未提交的长事务等等；割接窗口期内，待应用停止数据变更后，锁定生产库用户等等。
4. 迁移过程中生产系统的配合：A）迁移期间应避免DDL操作，禁止不刷redo日志的数据导入操作，停止rename表等操作；B）停止非必须的大事务、长事务等等。
明确数据校验策略
全量和增量阶段采取全行一致性比对策略。
反向同步阶段，由于业务无法停机，无法进行准确比对，多采用割接前进行多次反向同步验证（停库以便保证数据静止，再进行一致性比对）。
也可以在生产状态下，通过停止备库的方式进行一致性比对验证。
明确数据迁移步骤
为避免数据迁移失败，割接方案应细化到每个操作步骤的前置条件、操作指令、预期结果、操作时间等。
明确Sloth数据迁移调度策略
为确保全量数据迁移的速度，建议将全量迁移的任务按单分片复制表、多分片复制表以及水平分片表分开，单分片复制表的任务数是迁移服务器数的最小公倍数的N倍（N大于等于3），每个小任务的数据同步表都在同一个分片内，确保迁移任务均衡。
迁移回退策略
预先明确哪种场景必须回退，如关键数据表或数据库对象不一致或者不可用、关键业务测试验证不通过、性能不满足业务需要等等。对于非严重故障，只要提前有可靠的应急方案，可以不回退。
本期为大家讲解了基于金篆GoldenDB数据库迁移前，如何基于前期的调研信息制定数据迁移方案，下期将深入介绍数据库迁移过程，包含全量数据迁移、增量数据同步、引流切换和回流同步等，敬请期待。
公开资料显示，金篆GoldenDB是金融市场排名第1的金融级分布式数据库，银行业金融级分布式数据库市场份额占比为24.4%，银行核心系统市场投产数量占行业50%，银行次核心及非银核心系统市场投产数量占行业32%，这3项数据均为行业第1。金篆GoldenDB是目前国内唯一在大型银行、券商和运营商实现核心业务投产的国产数据库，核心系统案例覆盖国有大行、政策性银行、股份制银行、城商行、农商行、大型金融机构、券商、保险，具备支撑金融行业最核心业务系统的深厚实力和经验！
