浅析数据库的优化整合及数据迁移

浅析数据库的优化整合及数据迁移

刘莉 王茂利 柳正茂

中国联合网络通信有限公司河北省分公司  050051

   摘要：本文主要从核心和非核心分类对Oracle数据库进行优化整合。非核心数据库我们提出使用高度整合的数据库平台，利用Oracle 19C 容器的功能，提供以PDB形式承载周边非核心数据库，统一对外提供数据库服务，统一进行维护管理，且各数据库间独立运行。同时，对Oracle数据迁移MySQL的方式进行探究。关键字：数据库 优化  集群  资源  兼容

一、数据湖概述

数据湖是一种数据存储理念，存储企业各种各样的原始数据的大型仓库，包括结构化、非结构、二进制图像、音频、视频等等。

数据湖作为一个集中的存储库，可以在其中存储任何形式（结构化和非结构化）、任意规模的数据。在数据湖中，可以不对存储的数据进行结构化，只有在使用数据的时候，再利用数据湖强大的大数据查询、处理、分析等组件对数据进行处理和应用。因此，数据湖具备运行不同类型数据分析的能力。

数据湖能给企业带来多种能力，例如，能实现数据的集中式管理，在此之上，企业能挖掘出很多之前所不具备的能力。

另外，数据湖结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。

二、数据湖运行优势

Oracle9i、10g、11g等版本的生命周期已经结束，相关技术支持下降，过期数据库oracle不再提供安全补丁，数据存在安全隐患。

针对当前oracle数据库存在的问题，我们提出使用高度整合的数据库平台，统一对外提供数据库服务，对数据库统一进行管理。高度整合各系统数据库，统一对外提供数据库服务，统一管理，充分利用数据库资源，对外提供更稳定、更安全、更高效、更及时、易维护、高可用，弹性扩展以及性价比更高的数据库服务。把各系统数据库由原来的烟囱式改成现在的集群式，分权分域管理，提供集中管理方式下的分域协作功能，有助于核心设备资源共享和协同管理，节省配套投资，通过资源自由配置可灵活适应维护管理模式。

三、Oracle数据库优化架构

目前数据湖系统的管理方式多为普通的RAC 3节点集群，没有使用到Oracle12C之后的引入的CDB与PDB新特性，即一个数据库容器（CDB）承载多个可插拔数据库（PDB）；因此，需要将核心数据库升级到19C，以Non-CDB或CBD的1个PDB形式独占整套数据库集群的物理服务器资源，在原有的19C集群架构基础上，配置多租用户环境，将需要迁移入湖的系统，以租户的方式进行统一管理。

PDB(PLUGGABLE DATABASE)可以理解为我们Oracle 11g的数据库，只不过是一个实例上面可以放置多个数据库了。名称为插件式数据库。

CDB 容器数据库，作为插件式数据库的基石。所有的PDB都需要它，这里面有一个种子(seed)数据库的概念。可以以它为模板，克隆新的数据库。

四、数据库管理模式选型

选择Oracle 19C 多租户为数据湖平台的管理模式，为不同的业务创建不同的PDB数据库，在物理上进行隔离并且根据承载业务的特点我们对每个PDB设置合理的IO请求值和IO传输速率，有效利用系统资源。

五、数据库优化分析

（一）、技术层面：

在于可以利用现有存储设备，同时实现数据库多节点避免了单节点故障风险，在主机和存储性能上较以前在性能方面有很大提高，具体体现在以下方面：

●快速对外提供数据库服务

●集中管理数据库资源

●数据库版本统一

●充分利用数据库资源

●更高的可用性

●在线维护、数据库软件升级

●19c是长期支持版本，ORACLE持续支持到2026年

●根据需要灵活拔插迁移PDB

●选择19c的优势：19c通过了等保2.0的四级认证

（二）、客户使用层面：

数据库版本升级后，对应的数据库连接驱动、库文件都会发生变化，因此对现有应用程序的使用会产生一定的影响，建议对相关应用程序的ORACLE客户端，JDBC驱动程序进行统一升级，并且对业务功能和性能进行全面测试。

（三）、资源层面：

数据库由原本的一对一的关系，改变成一对多的关系，大大节省了资源的占用，后期维护成本也相对减少了很多，通俗的说也就是原本应支付十套的维保付费用，节省至一套。

六、迁移可行性方案探究

现今，Oracle数据迁移MySQL的需求已经越来越普遍，对数据库的访问需求和安全、健壮、平稳运行要求更高，避免由于硬件或人为误操作引起的数据库单点故障，提供数据库高可用、达到前端无感知切换等目的，因此采用MySQL数据库集群的改造方案。主要的迁移场景大致可以分为三类，第一类是涉及小表以及少量表的一次性迁移，无需进行增量同步，第二类是涉及大表以及多表的一次性迁移，第三类是涉及增量实时同步，而对于数据的迁移方法，常见的方式有使用第三方的同步工具CDC进行Oracle到MySQL的数据迁移、使用开源的同步工具以及应用层面进行迁移同步。

根据上述分析，可以根据不同场景、不同业务类型、不同数据属性来分类、分批、分级的来实现Oracle到Mysql的迁移。元数据使用Nvaicat实现迁移，存量和历史数据使用DataX或sqluldr2实现迁移，实时数据使用Ogg实现迁移。

需要注意的是， MySQL Router可以使用–bootstrap选项基于InnoDB Cluster的元数据进行自我配置。这会自动配置MySQL Router以将连接路由到群集的服务器实例。客户端应用程序连接到MySQL Router提供的端口，无需了解InnoDB Cluster拓扑。如果发生意外故障，InnoDB Cluster会自动调整，MySQL Router会检测到更改。这消除了客户端应用程序处理故障转移的需求。MySQL不建议手动配置MySQL Router以重定向到InnoDB Cluster的端口，而是建议始终使用–bootstrap选项，因为这可确保MySQL Router从InnoDB Cluster的元数据中获取其配置。使用生产部署时，建议将MySQL Router部署于客户端应用程序所在的每台计算机上。

参考文献：

《Oracle 19C数据库应用》 张华 著 清华大学出版社

《Oracle 19c从入门到精通》 王英英 著 清华大学出版社

《数据库原理与应用（Oracle19c版）》杨晨 主编 清华大学出版社