Oracle的多租户和MySQL,MSSQL的类似,把之前的一个实例对一个数据库的情形(RAC是多个实例对一个数据库)整合成了一个实例下可以挂多个数据库,并且定义为可插拔的,听起来很炫。就像在没有多租户特性之前,Oracle与MSSQL以及MySQL还是有很大的差异,因此对于Oracle的多租户也有一些不同的地方。本文主要描述Oracle 12c多租户架构。
一、多租户概念
Oracle多租户环境包含一个容器数据库(CDB)和零个或多个可插拔数据库(PDB),一个PDB是一个模式,模式对象,以及非模式对象,如到一个Oracle网络客户端作为非CDB。Oracle 12c之前的版本,都是非CDB数据库。
借用从MSSQL或者MySQL架构来看,即一个实例下面可以有多个数据库。Oracle这个多租户其实和他们的架构类似,把PDB按这种思路来理解就容易得多了。这么做最终的目的是可以充分的利用系统资源。想之前维护的一台机器上搞了5-6个实例,资源浪费,管理起来也费劲。
二、CDB容器
1、什么是CDB容器
一个CDB容器是多租户架构内的数据或元数据的逻辑集合。
下图为CDB中容器示例
每个CDB都有以下容器:
CDB根容器(也简称根)
该CDB根是一个模式,模式对象,以及属于所有PDB的非模式对象的集合。根容器存储Oracle提供的元数据和公共用户。元数据的一个例子是Oracle提供的PL/SQL包的源代码。公共用户是每个容器中已知的数据库用户。根容器被命名CDB$ROOT。系统容器
该系统包括根CDB和在CDB所有的PDBS。因此,系统容器是CDB本身的逻辑容器。零个或多个应用程序容器
应用程序容器只包含一个应用程序根目录,并且PDB插入到该根目录中。而系统容器包含CDB根目录和CDB 内的所有 PDB,应用程序容器仅包含插入应用程序根目录的PDB。应用根属于CDB根,没有其他容器。零个或多个用户创建的PDB
一个PDB包含特定功能集所需的数据和代码。例如,PDB可以支持特定应用,如人力资源或销售应用。您可以根据业务需求添加PDB。
PDB属于零个或一个应用程序容器。如果PDB属于应用程序容器,那么它是一个应用程序PDB。例如,cust1_pdb与cust2_pdb应用PDBS可能属于该saas_sales_ac应用程序容器,在这种情况下,他们不属于任何其他应用程序容器。应用程序种子是可选的应用程序PDB,用作用户创建的PDB模板,使您能够快速创建新的应用程序PDB。一个种子PDB
种子PDB是CDB可用于创建新的PDB的系统提供的模板。种子PDB命名PDB$SEED。您不能添加或修改对象PDB$SEED。
2、没有应用容器的CDB
此示例显示一个简单的CDB,其中包含五个容器:系统容器(整个CDB),CDB根,PDB种子和两个PDB。每个PDB都有自己的专用应用程序。不同的PDB管理员管理每个PDB。一个公共用户存在于具有单个身份的CDB上。在这个例子中,公共用户SYS可以管理根和每个PDB。在物理层面上,该CDB具有数据库实例和数据库文件,就像非CDB一样。
如下图没有应用程序容器的CDB
3、带有应用程序容器的CDB
在本变体中,CDB包含一个名为的应用程序容器saas_sales_ac。在应用程序容器中,应用程序PDB cust1_pdb支持一个客户的应用程序,并且应用程序PDB cust2_pdb支持不同客户的应用程序。CDB还包含一个名为的PDB hrpdb,它支持HR应用程序,但不属于应用程序容器。
下图为带有应用程序容器的CDB
在这个例子中,多个DBA管理CDB环境:
CDB管理员管理CDB本身。
应用程序容器管理员管理saas_sales_ac容器,包括应用程序安装和升级。
应用程序PDB管理员管理的两个PDBS saas_sales_ac容器:cust1_pdb和cust2_pdb。
PDB管理员管理hrpdb。
三、CDB要点理解
- 一个多租户数据库有一个CDB容器,可以理解为一栋写字楼。
- 多租户数据库有一个数据库实例,一个系统全局区以及一组后台进程,可以理解为写字楼的物业,安保人员等等,服务于所有租户。
- 有零个和多个PDB数据库,可以理解为各个企业在当前写字楼租用的办公室。有些企业有多间办公室(多个PDB服务与某个特定应用程序),有些企业只有一间办公室(单个PDB及应用程序)。
- 根容器中定义的对象可以由所有PDB共享及访问。可以理解为写字楼的公共区,如电梯,楼台,公共洗手间等。
- 各个PDB服务通过数据库监听器提供给用户,可以理解为写字楼大厅水牌,按照水牌,即可以找到对应公司具体楼层及位置。
- PDB内定义的对象为私有的,每个PDB都有自己的数据字典。可以理解为不同的企业财务,业务各自独立,如有业务往来,那就签协议(fast intra-CDB dblink)
四、多租户架构的优缺点
1、非CDB架构的挑战
整合前,如下图所示
- 整合前集中常见的架构情形
N多的应用服务器对应到N多的数据库服务器 #Author : Leshami
几个或N个数据库服务器实例放在同一台服务器 #Blog : http://blog.csdn.net/leshami
- 存在的问题
DBA团队必须分别管理每个数据库的SGA,数据库文件,帐户,安全性等
大部分系统资源变成闲置,即使是在一台服务器上放置多个实例,本质上依旧是单独管理(数据库级别)
各个数据库之间的交互远程调用效率低下(dblink)
2、整合后的优点
整合后图示如下:
- 整合的实质
将数据从位于不同服务器上的多个数据库合并到一台服务器上,且无需更改现有模式或应用程序
-
整合后的优点
降低成本(10台服务器变成1台,共享进程,共享系统资源)
更容易和更快速的数据和代码的移动(可拔插数据库,像U盘一样,能不快速吗)
更轻松地管理和监控物理数据库(至少不用连接N多服务器来观察)
分离数据和代码
安全分离管理权限(各个PDB之间的权限依旧独立)
轻松性能调优(不用看辣么多的AWR,不用研究是不是哪个服务器SGA多了,哪个PGA少了)
补丁升级更容易,一次搞定N个数据库(绿盟很厉害,一扫N台数据库都得打补丁)
系统管理员不需要分配辣么多的oracle用户了
3、整合后的缺点
DBA管理人员锐减,要失业了
每一个调整都要当心了,牵一发动全局,你懂的
发现中……