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管理人员锐减，要失业了
每一个调整都要当心了，牵一发动全局，你懂的
发现中……
