从Oracle到国产数据库迁移实践.docx

从Orac1e到国产数据库迁移实践来自twt社区同行交流,欢迎更多同行参与交流如果数据库较大，全量迁移时间较长，如何尽可能缩短停机窗口？对于数据库容量较大的库，从OraC1e迁移到国产数据库，全量迁移需要较长时间，而对于金融机构来说，停机窗口非常宝贵，如何可以缩短停机窗口是实施的难点之一，如果是同构数据库的迁移，比如OraCIe迁移到OraCIe,有比较成熟的工具实现全量和增量的迁移，前期先进行全量迁移，停机窗口时再进行增量迁移，可以尽可能缩短停机时间，但是OraCIe到国产数据库，如何进行类似的全量和增量迁移，需要重点考虑？问题来自社区会员张晓斌先生（某大型国企保险公司信息技术支持），探讨来自twt社区众多同行的分享，欢迎大家参与交流，各抒己见。huawei851120江苏省农村信用社联合社数据库运维工程师：有两种思路：1,先对OraC1e的大表进行改造，分为历史表和当前表。把历史表先期迁移到国产数据库，停机窗口内再把当前用的表迁移过去。这种用法比较推荐;2,利用同步工具。几家大厂的国产数据库，都有自己的数据同步工具，可以先期进行数据同步，但不能同步DD1。这个阶段不要进行OraCIe表结构的表更。投产窗口内，把应用停掉后，等数据追平就可以了。刘炜钮城银清算服务有限责任公司应用维护：1、截止到一个时间点可以提前迁移历史数据，比如窗口前一周或者提前1、2天；2、到了停机窗口，业务停运后补增量数据；3、做好全量数据的检查，补完增量后，新老库数据量对比，做最终确认，这样就能大大减少数据迁移时间。hanfeng_twtSphereEx数据库架构师：总结来说，是异构数据库间迁移的问题。1提供常规的全量及增量数据迁移能力，这对于有效缩短时间窗口有益。目前已有很多厂商提供此类能力。但需要注意的是，从集中式架构到分布式架构还可以；反之仍有一定局限。2 .提供全量及增量数据对比能力，满足对数据一致性的检验能力，这对于实施切换是重要参考依据。此外包括差异数据的正向、反向的补偿能力，也是需要的。3 .由业务逻辑方面提供一定的兼容能力，可满足短时间系统间迁移的数据补偿能力，有助于缩短窗口。4 .架构设计方面，提供多种数据同步考虑，除了数据库外，还可以考虑如应用报文、网络协议等方面的同步机制，作为有益的补充。-全文完-