Oracle及MySQL数据库迁移至国产数据库软件中,一般是基于应用程序实现迁移还是基于数据库厂商提供的迁移工具,哪种方式较好,迁移过程中需要关注哪些难点呢?
一定要基于数据库厂商提供的工具!其他行业我不知道,在金融行业,人民银行发布的有金融行业数据库标准 《分布式数据库技术金融应用规范》( JR/T 0204—2020),明确要求厂家提供数据迁移工具。没有这个工具就别在金融行业混饭吃,换句话说重点,数据迁移的风险必须由国产数据库厂商来负责!
哪能让研发人员写sql和脚本来承担,一些小系统的话,我相信研发人员能搞定。但是如果出现意外,数据脏了,乱了,少了,这个风险难道让是DBA承担?还是让软件开发部门的项目经理承担?还是让做软件开发的外包公司承担?都承担不了的,必须把数据迁移的风险牢牢的扣在国产数据库厂家的头上,吃这碗饭必须承担这个风险,否则去其他行业混就行了。
最好在迁移前可以做迁移评估,然后根据评估结果来制定迁移策略,制定逃生计划。 如果用OceanBase 可以用他们的OMA评估工具先跑一下迁移评估,根据结果来做,我们在几个商业银行的核心系统做主机下移的项目上就都是做了逃生集群确保万一故障可以随时切回原DB2 主机。
OMA工具还是非常好用,会细化到SQL级别的语句和代码,可以直观地看到涉及到不同应用的代码改造量,然后制定迁移评估策略,迁移演练,实际迁移可以用到OMS 的工具,如果数据库较大,从ORACLE迁移到国产数据库,全量迁移需要较长时间,停机窗口就非常宝贵,缩短停机窗口是实施的难点之一,如果是同构数据库的迁移,比如OceanBase的OMS迁移工具就是比较成熟的工具,可以实现全量和增量的迁移,前期先进行全量迁移,停机窗口时再进行增量迁移,可以尽可能缩短停机时间
应用程序处理迁移会比较靠谱,因为数据不是直接照搬到国产数据库就能使用的,需要根据应用程序适配国产数据库的情况,做数据处理,中间涉及表结构的更改,数据的调整等等一系列动作。
收起对于银行行业来说,数据库迁移是一项非常重要的任务,因为银行的业务数据非常庞大且敏感,因此需要谨慎处理。针对Oracle及MySQL数据库迁移至国产数据库软件中,一般可以基于应用程序实现迁移或者基于数据库厂商提供的迁移工具来实现。
基于应用程序实现迁移的优点是可以更好地控制迁移过程,可以根据具体的业务需求进行定制化的迁移方案,同时也可以减少对数据库的影响。但是这种方式需要开发人员的参与,需要对应用程序进行修改,因此需要一定的技术实力和时间成本。
基于数据库厂商提供的迁移工具的优点是可以快速完成迁移,而且一般都有比较完善的迁移方案和工具,可以减少迁移过程中的风险。但是这种方式可能会对数据库的性能产生一定的影响,需要在迁移前进行充分的测试和评估。
在进行数据库迁移时,需要关注以下几个难点:
总之,数据库迁移是一项非常复杂的任务,需要进行充分的评估和规划,同时也需要谨慎处理,确保数据的安全和完整性。