前言：Oracle数据库12c版本2(12.2),最新一代的ORACLE数据库现在已经在甲骨文云端可用了,相信On-Premises版本很快就可以提供给客户，作为12c数据库核心特性的多租户有哪些增强呢,让我们通过OOW上透露出的一些信息先行了解一下。
首先让我们简单回顾一下多租户架构的优势
每个应用程序有独立的 PDB
应用程序无需更改即可运行
快速供应（通过克隆）
移植性（通过可插拔性）
共享内存和后台进程
每个服务器运行更多应用程序公共操作在CDB 级别执行
将多个数据库作为一个管理（补丁、升级、高可用、备份）
细粒度控制在适用的时候
再让我们一起看看12.2版本中的主要增强：
数据库供应增强-在线操作数据库供应（多租户克隆）的演进
多年来，在大多数典型的工作日，数据库管理员需要投入大量时间来创建新数据库、将现有数据库从一台机器迁移到另一台机器上，以及出于开发、测试和问题诊断等各种目的创建现有数据库的最为当前的克隆版本。
在12.1版本中使用冷克隆，PDB需要只读或者拔出，在12.2版本中实现了热克隆。
热克隆技术如何实现
1. 源PDB仍然开放的读/写
2. 并行读取和复制
3. 正在进行的操作隐含“脏读”
4. 一些数据变化是不包括在最初的文件副本
5. 传输和应用redo数据用于追上源数据库改变
6. 应用UNDO来回滚未提交的事务
在12.2 多租户中我们通过上述步骤完成PDB在线克隆，如下图所示：
在线操作（PDB克隆、PDB刷新、PDB迁移）
通过热克隆技术，诸如PDB克隆、PDB刷新、PDB迁移均得以在线进行，这将最大程度提高数据库供应速度、减少对源生产系统的影响并保证数据的实时性。
在12.2中,为了解决SaaS需求,我们引入一个新的概念,应用程序容器Application Container。应用程序容器包含应用程序的根,可选的一个租户种子和零个或多个pdb租户。仅需一次安装应用程序定义在应用程序的根，从那里可以创建租户种子，此后新租户供应简单的通过克隆租户种子。如下图所示：
闪回PDB现在完全支持。
支持整合的pdb使用不同的字符集。
12.1中252个pdb是一个不错的数字,但在12.2我们增加了16倍至4096个。(即4k)。
AWR数据在PDB级别允许,可以针对特定的PDB进行细粒度的性能诊断。
在12.2多租户中,热图得到完全支持。这意味着在12.2多租户架构中完全能够通过Oracle自动数据优化(ADO)提高存储利用效率。
锁定配置文件
通过使用Lockdownprofile增加了对权限管理的细粒度控制能力，作为对授权操作补充，如下图所示，将开发用户的alter sytem权限限制在设置plsql_debug等3个代码相关的方面，而不允许其修改优化模式、并行度等系统级参数。
Data Gurad Broker为多租户所作的增强
支持单个PDB级别的故障转移。为此有两对CDB在两个服务器上,每对一主一备，复制方向相反,当发生PDB级别的故障时,备库的PDB迁移到相同服务器上的另一个CDB上，变成了一个新的主PDB。由于同一服务器存储是共享的,无需物理上复制或迁移数据文件,因此这可以达到最少的停机时间。
资源管理增强
在12.1中,我们可以定义资源管理器的策略来控制CPU、I / O(但只有Exadata和SuperCluster),session和并行执行(PX)服务器。我们在12.2显著提高了这种能力。在12.2中我们对于non-engineered系统增强了内存管理和I / O管理能力。
对于non-Exadata存储，在12.2中引入了两个新的per-PDB参数Max_IOPS和Max_MBPS来控制IO使用,可以动态地设置和改变，但不能在CDB根或Exadata上设置这两个参数，否则会返回错误信息。在12.2中也引入了CPU_Count作为PDB-level参数。
在per-PDB级别还增加了对如下参数的支持：
SGA_Target Maximum SGA size for PDB
SGA_Min_Size(New in 12.2) GuaranteedSGA size (for buffer cache and shared pool) for PDB.
Tip: Sum ofSGA_Min_Size across all PDBs should be <50% of SGA.
DB_Cache_Size Guaranteed Buffer Cache size forPDB
DB_Shared_Pool_Size Guaranteed Shared Pool size for PDB
PGA_Aggregate_Limit Maximum PGA size for PDB
PGA_Aggregate_Target Target PGA size for PDB
下面通过一张图再简要回顾一下12.2版本多租户在这几个方面的增强
成百上千的数据库分散运行于客户站点中几乎同样多的机器上，导致站点规模庞大，这种情况如今是相当常见。随之而来的不菲开支促使组织主动采取行动，将众多数据库集中到一起，换而言之就是整合，以便降低成本。过去数十年中，数据库管理员花费了比其预想更多的时间，用于供应数据库，为众多数据库分别进行Oracle 版本修补，规划、建立以及管理备份和灾难恢复方案，或者需要更多管理员分别管理每个数据库（作为每个数据库各自的持续活动）。
12.2多租户架构更好的解决了这些客户面对的难题，赶快登入甲骨文云端去体验吧。
