23ai DGPDB，Oracle资源池战略的最后一块拼图

数据最前线

于 2024-09-15 21:58:44 发布

阅读量440

点赞数 15

文章标签： oracle 数据库

本文链接：https://blog.csdn.net/oracle18c/article/details/142289646

版权

Oracle对资源池是有执念的！

在我看来，这种执念一方面是应用架构的微服务化，数据库被拆分的越来越小，而服务器的硬件能力是不断提升的，CPU核心数、内存和存储的容量都按照摩尔定律在不断增加，这就使得数据库服务器资源使用率长期维持在一个非常低的水位；另一方面来源于当今科技发展对资源精细化管理的需求，尤其是虚拟化、容器化技术的发展，让精细化资源管理变得触手可及。但数据库是个强一致性的节点，如何更好的实现这一点，是数据库厂商不断探索和追求的目标。

今天我们梳理了Oracle的资源池路线，看看Oracle数据库是如何从传统的多进程架构演变成适应云时代数据库精细化管理需求的。

11g 资源池

11g时代，Oracle Cloud Control产品中提供了一个资源管理门户 – Oracle Cloud Self Service Portal，利用这个门户可以将多个数据库或集群构建成资源池。为了满足不同业务系统的需求，可以采用不同的设备构建多种级别的资源池，比如Exadata资源池，用于高性能分析系统；普通X86资源池，用于支持中等压力的业务系统。当业务系统需要数据库资源，即可从不同的资源池中分配需要的资源。

由于架构上的限制，11g资源池只能支持数据库级和Schema两个级别，Schema资源隔离能力较弱，大多数用户并不愿意将多个业务系统的数据放在同一个数据库中；而如果采用数据库级的资源池，本质上就是新建了一个数据库，和手工创建一个独立的数据库，并没有什么差别。因此使用11g资源池的用户非常有限，即使是在一套集群上创建了多个数据库，用户也没把它称为是资源池。

随着微服务架构的流行，一套应用系统可能被拆分为多个数据库来支持。一方面，单个数据库消耗的资源显著下降，很多用户的服务器资源利用率不到10%；另一方面，Oracle新建一个数据库需要多出一组实例(一大堆的后台进程)，这也使得管理成本明显增加。

因此Oracle的多实例单数据库的架构，在这个追求快速弹性扩缩容的时代，多少显得有些格格不入。

12c 多租户

12c中引入了多租户架构，一个容器数据库(Container Database, CDB)中可以容纳多个可插拔数据库(Pluggable Database, PDB)。虽然说从架构上CDB相当于是原来的独立数据库，但Oracle期望CDB作为数据库的容器，PDB作为最小的数据库单位，可以在不同的CDB之间便利的迁出和迁入。当应用需要新的数据库资源时，只需要一条命令在CDB中创建出新的PDB即可交付使用。
在这里插入图片描述

这种使用方式，大家是否有些似曾相识，事实上MySQL和SQL Server等数据库一直就是这种架构，Oracle兜兜转转走了一大圈的“弯路”，似乎又回到了“原点”。不过Oracle毕竟是商业数据库的头牌，相比于MySQL，PDB更像是一个独立的数据库，在不同CDB之间的迁移更加方便；相比于SQL Server，PDB的内存、CPU和I/O资源隔离更加彻底，彼此之间可以最大程度上不受干扰。

当使用多租户将多个独立数据库作为迁入PDB之后，企业用户却发现一个尴尬的问题 – 容灾切换只能以CDB级别来进行，这就意味着如果一个PDB业务需要做容灾切换，整个CDB上的数据库都得配合，这是完全不可接受的。虽然可以用冗余CDB来进行中转，但是和传统切换方式相比更加繁琐，切换耗时也更长，很多用户并不愿意接受这种方案。

因此容灾切换的不便，成为12c资源池推广路上最大的绊脚石。

23ai DGPDB

2022 年 7 月，Oracle在 21.7版本引入了PDB级Data Guard特性(简称：DGPDB)，这个多租户新的Data Guard特性将用来替代传统的CDB架构层的Data Guard，用户即可以部署CDB层的Data Guard，也支持更灵活的PDB层Data Guard(在每个PDB上配置、维护和独立的Switchover、Failover操作)。

PDB层的Data Guard保护的是单个PDB，而不是整个CDB。在这个架构中，主备两端的CDB都是Primary角色，运行在CDB上的PDB即可以是Primary也可以是Standby，PDB级的Primary和Standby构成一组Data Guard。

在这里插入图片描述