企业传统Oracle数据库迁移到国产数据库核心难点总结.docx

《企业传统Oracle数据库迁移到国产数据库核心难点总结.docx》由会员分享，可在线阅读，更多相关《企业传统Oracle数据库迁移到国产数据库核心难点总结.docx（11页珍藏版）》请在第一文库网上搜索。

1、企业传统Orac1e数据库迁移到国产数据库核心难点总结背景近几年国产数据库以其高并发、海量数据、易扩展、高可用、易运维（一体化自动运维平台）等技术优势，以及其部署在普通硬件服务器之上的成本优势，在国内各个行业取得了广泛应用，成熟度也越来越高，关注程度也越来越高，在金融行业尤其是银行业数据库国产化替换的趋势越来越明显：在银行业数字化转型和高质量发展过程中，IT系统的飞速发展，而传统以OraCIe为代表的集中式IT架构已经无法满足需求，像云平台、大数据、AI、微服务、分布式架构、敏捷前台、统一中台等技术架构的发展很好的契合了银行未来业务发展的需求，而国产数据库作为其中重要环节贯穿了整个前中后端，重

2、要程度不言而喻，是未来银行IT架构转型发展的重要趋势；此外，金融行业国产化进一步推进并逐步进入深水区，数据库国产化是其中一项重要内容，数据库从传统Orac1e迁移到国产数据库势在必行。本文重点围绕企业在去0实践过程中遇到的难题进行交流探讨总结：1、由Orac1e数据库迁移到分布式数据库之后，关联查询的语句怎么解决？【问题描述】由OraC1e数据库迁移到分布式数据库之后，除了让尽量把需要关联的表按照相同的规则分布在一个节点外，现在系统的数据量都是5T以上的，不同的表已经按照不同的规则进行了分区，这些表之间的关联查询是应用必须要的而且频率很高，如果需要把所有的表按照统一规则去设置分布字段让同一用户

3、下的资料都相同的节点上，这样的话改造就非常大，万一要回退也会非常麻烦，请问一下专家，这个问题还有没有其他好办法来解决复杂的关联查询的问题，又不会导致应用改造过大？hanfeng_twtSphereEx数据库架构师：解决上述问题有几个思路：1 .产品层面有些分布式数据库产品，提供“自动分布式”能力，即可以实现数据自主分片，不再需要人为干预。这样在结构设计无需做太多修改。针对语句方面，也可以免改造或低改造完成迁移。当然这种方式还是要看业务复杂度，很难做到完全规避因引入分布式带来的改造成本。且针对复杂查询情况下，目标数据库是否能很好处理且保证性能也是需关注的。2 .设计层面在设计方面，提前做好相应的

4、改造评估工作。如对现有结构、语句通过工具扫描方式，获得当前的工作负载，针对分布式情况下做改造评估等。这种方式不会减少改造工作量，但会提前规划避免被动。这种也是我比较推荐的方式。3 .架构层面针对复杂的OraCIe查询，有些场景可考虑下移到大数据技术栈解决。后者针对复杂关联查询，会更为适合。但两者需解决数据同步问题且业务是否接受一定延迟，也需关注。2、如果数据库较大，全量迁移时间较长，如何尽可能缩短停机窗口？【问题描述】对于数据库容量较大的库，从OraCIe迁移到国产数据库，全量迁移需要较长时间，而对于金融机构来说，停机窗口非常宝贵，如何可以缩短停机窗口是实施的难点之一，如果是同构数据库的迁移，

5、比如Orac1e迁移到Orac1e,有比较成熟的工具实现全量和增量的迁移，前期先进行全量迁移，停机窗口时再进行增量迁移，可以尽可能缩短停机时间，但是OraCIe到国产数据库，如何进行类似的全量和增量迁移，需要重点考虑？hanfengtwtSphereEx数据库架构师：总结来说，是异构数据库间迁移的问题1 .提供常规的全量及增量数据迁移能力，这对于有效缩短时间窗口有益。目前已有很多厂商提供此类能力。但需要注意的是，从集中式架构到分布式架构还可以；反之仍有一定局限。2 .提供全量及增量数据对比能力，满足对数据一致性的检验能力，这对于实施切换是重要参考依据。此外包括差异数据的正向、反向的补偿能力，也

6、是需要的。3 .由业务逻辑方面提供一定的兼容能力，可满足短时间系统间迁移的数据补偿能力，有助于缩短窗口。4 .架构设计方面，提供多种数据同步考虑，除了数据库外，还可以考虑如应用报文、网络协议等方面的同步机制，作为有益的补充。鲂UaWei851120江苏省农村信用社联合社数据库运维工程师：有两种思路：1.先对OraC1e的大表进行改造，分为历史表和当前表。把历史表先期迁移到国产数据库，停机窗口内再把当前用的表迁移过去。这种用法比较推荐；2.利用同步工具。几家大厂的国产数据库，都有自己的数据同步工具，可以先期进行数据同步，但不能同步DD1。这个阶段不要进行OraC1e表结构的表更。投产窗口内，把应

7、用停掉后，等数据追平就可以了。刘炜钮城银清算服务有限责任公司应用维护：1 .截止到一个时间点可以提前迁移历史数据，比如窗口前一周或者提前1、2天；2 .到了停机窗口，业务停运后补增量数据；3 .做好全量数据的检查，补完增量后，新老库数据量对比，做最终确认，这样就能大大减少数据迁移时间。yata52中国人寿财险数据库管理员：目前我们接触的国产数据库厂商都有了适合自己的全量初始化加增量同步方案，有的是利用自有工具，有的是利用常见数据迁移软件，都能做到在切换前数据实时同步几乎无延迟。但是总结下来，迁移的过程还需要重点考虑这几个问题：1如果源库较大，为了保障全量初始化成功，需要考虑适当调大Undo表空

8、间，为了保障迁移时对生产影响较小，尽量使用物理备库抽取，全量迁移时合理分组初始化。如果是单表过大又没有物理备库的情况，可以考虑使用更高效的工具（数据泵等）将单表迁移至OraC1e中转库（不承载业务）再慢慢导入到国产数据库。2 .如果迁移过程中使用了kett1e、ogg、平面文件多种技术组合实现，上线前一定要对数据做验证，防止出现中文乱码。3 .各家都实现了实时增量同步，目前切换过程中占用停机时间的主要是这两个步骤，一是数据静态后的数据检验时间，二是反向同步启动前的配置和检查工作。3、国产数据库分集中式和分布式，OraCIe迁移至集中式还是分布式场景？【问题描述】国产数据库有提供集中式模式和分布

9、式模式两种，集中式省去了数据分布方面的难点，更容易实现迁移，但是性能、容量和扩展性受限，而分布式数据库改造难度相对较大，但性能、容量和扩展性优势明显，因此，如何更加具体业务场景选择合适的数据库？huawei851120江苏省农村信用社联合社数据库运维工程师：1 .首选无论是集中式还是分布式，都尽量采用大厂的产品。因为数据迁移工作，看似没什么大不了，一旦出问题后后果很严重。大厂的集中式和分布式产品一般都有数据迁移工具，并且在很多客户那使用过，迁移都会比较方便,但没有想象的完美。2 .如果是小库，迁移至集中式会比较方便，通过工具直接可以迁移。如果是交易量比较大、数据量比较大的库，推荐采用分布式数据

10、库，集中式的性能肯定不如大厂的分布式数据库产品。3 .如果库有非常多的存储过程（几十个，乃至几百个），还是采用集中式比较好。分布式数据库，尤其是基于MySQ1的对存储过程兼容性不太好。yata52中国人寿财险数据库管理员：首先总结下我司所使用的两种数据库特点：集中式数据库：体系结构与Orac1e类似，语法兼容度高、对服务器无要求、数据迁移成本小、运维规范可基本沿用。单集群性能上限受限于X86服务器算力，相比小型机+Orac1e的组合仍存在一定差距。分布式数据库：使用分布式协议和1SM-Tree数据结构，需要修改为Mysq1语法、对服务器性能要求较高、数据迁移成本较高、运维规范需重新建立。单集群

11、库性能可通过扩充服务器进行扩展，算力可突破小型机+Orac1e的组合。针对以上两种特点，我们的替换场景如下：1 .切换前使用虚拟机运行数据库的中低负载系统，替换为集中式数据库。2 .切换前使用小型机或者多台物理机运行数据库的中高负载系统，替换为分布式数据库。1u1ihuan1987张家港行数据库管理员：国产数据库集中式模式迁移难度较小，适配容易，特别是一些特殊数据库对象也可以支持，比如函数和存储过程，对于性能，容量和扩展性要求不高，单台数据库服务器足以支撑的业务场景，可以采用。而分布式模式对于数据库比较大，高并发，需要根据业务需求可以扩展的业务场景，单台服务器无法支撑的场景。无论是集中式还是分

12、布式模式，均支持跨机房级容灾和节点高可用等特性。hanfengtwtSphereEx数据库架构师：从Orac1e迁移到国产数据库的选择路线：1 .迁移目的：首选需要关注的是迁移目的，是为了解决性能、承载量，还是为了满足自主可控。针对前者的话，考虑分布式架构更多；后者，则更倾向于考虑国产集中式架构产品。2 .应用适配：次之要考虑应用适配问题。如果应用对OraCIe有较深度的依赖，则需优先考虑兼容度好的产品，相对而言集中式架构产品在这方面有些优势；反之，则可不将此因素作为选择要素之一。此外，针对分布式架构，需要考虑如数据分片等问题，也需一并考虑。某些系统依赖外部厂商开发，出于尽量减少开发量的初衷，

13、集中式架构更有优势。3 .运维适配：现有运维体系是否对分布式架构有一定经验或者已具备相关人员储备，这对于选择这一架构很重要。这其中包括从基础设施、备份恢复、故障处理、性能调优等多方面。4 .业务连续性：相对集中式架构而言，分布式在整体稳定性等方面还需验证。因此在选择之初，要将整体可用性作为考虑要素之一，是否有专项预案解决需考虑。4、正式替换原有数据库后，如何保证国产数据库写库的准确性？是否有异构数据库之间的数据稽核？【问题描述】在双轨运行过程中，如何保证国产数据库写库的准确性？我们之前测试的时候发现有些国产数据库保存的精度与Orac1e不一致。是否有异构数据库之间的数据强一致性的稽核？huaw

14、ei851120江苏省农村信用社联合社数据库运维工程师：据我了解，应该是没有的。本人也是希望有，这样可以防止国产数据库出现天大的问题（数据不一致）的时候，我们客户能及早的发现，不至于酿成大错。可是目前国内应该没有这样的异构数据库之间的数据稽核。小厂商都是基于MySQ1和PG开发的，不值得大厂去开发工具稽核它们。大厂的数据库核心技术都是保密的，不会给别的大厂去稽核。我是个小胖子国泰君安：根据我们前面的应用经验，这种稽核一般是有两种方式。一是由数据库厂商提供相关的工具，来核对两个库的数据一致性，比如两边分别导出CSV文件（排除自增id,时间戳等字段），然后进行比对，也可以以OraCIe数据库基准，

15、用唯一键定位国产库的行数据，然后进行比对。二是由业务每日导出当日的增量数据，然后由业务方自行比对。5、风险控制方面考虑，例如白名单灰度迁移，回退方案等？【问题描述】迁移过程中风险必须是可控的，由于是对于重要在线业务系统,一方面要确保业务系统尽可能短暂的影响，又要确保出现问题能够快速应对或者回退，该问题难点在于涉及数据库的切换，如果只涉及应用，那么可以通过灰度发布实现，出现问题也可以及时回退，而数据库的迁移是否可以借鉴类似的思路去实现白名单灰度迁移，出现问题快速回退，整个过程中Orac1e和国产数据库之间的数据如何处理？huawei851120江苏省农村信用社联合社数据库运维工程师：从我们的经验

16、看，灰度迁移是个危险的想法，哈哈！真的，容易把数据搞脏掉，不建议这样做。虽然整体数据迁移，风险高，但是容易保持数据一致性。一旦失败后，可以追日志来找到数据一致点。至于您担心的事情，我个人的意见是：1提前把国产数据的环境搭好，小库要提前两周，大库要提前一个月。2 .在生产上，切换投产窗口前提前做几轮的迁移测试。比如9月1日迁移，在8月中旬下旬各做两轮的迁移，在生产上做的话，注意窗口，以防对现有系统造成影响。可以选择深夜交易低谷进行。3 .每轮迁移完成后，对数据进行校验和比对。yata52中国人寿财险数据库管理员：目前我们接触到的国产数据库厂商暂时还做不到同时双向同步，即同一个表内的数据Orac1e的变更向国产写，同时国产的变更向Orac1e写。但是目前都实现了单向同步，Orac1e的变更向国产写没问题，切换之