Oracle19c中的CDB与PDB

Oracle 12C引入了新特性多租用户环境（Multitenant Environment），它允许一个数据库容器（CDB）承载多个可插拔数据库（PDB）。CDB全称为Container Database，即容器数据库，PDB全称为Pluggable Database，即可插拔数据库。在Oracle 12C之前，实例与数据库是一对一或多对一关系（RAC）,而不能实现一对多的关系。在Oracle 12C中，基于多租用户环境这一新特性，实现了实例与数据库的一对多关系。 下图是官方文档给出的CDB与PDB的关系图。

一个root容器是所有PDB共享的用户，用户对象以及非用户对象的集合。

每一个CDB里面包含了以下的容器，这里说的CDB不是一个概念，而是一个整体：

1，有且只有一个root

root存储着oracle提供的元数据以及公共用户。比如说oracle提供的PL/SQL包的源代码就是元数据中的一类。公共用户则是指每个容器都能够看到的数据库用户。

root容器的名字是CDB$ROOT。

2，有且只有一个seed PDB

seed PDB是一个系统提供的模板数据库，CDB可以使用它来创建新的PDB，但是你不可以增加或者修改里面的对象。它的名字是PDB$SEED。

3，0或者多个用户创建的PDB

PDB是用户创建的实体，它可以包含用户的数据和代码，比如说对应单个应用或者单个应用模块，比如说给HR应用或者sales应用。在CDB创建的过程中是不会包含任意一个PDB的，你需要基于你的业务需求来创建PDB。

下图显示了一个典型的CDB结构，包含了一个root，一个seed以及两个PDBs。

每个PDB都有它自己的直属应用，以及单独的PDB管理员。

并且在整个CDB中有一个公共用户SYS，在这个例子中，可以看到CDB把root以及所有的PDB给包围起来了，CDB的管理用户（公共用户）SYS同样可以管理root和所有的PDB。

在物理层面，这个CDB的存储结构跟普通的non-CDB是一样的。

多租户特性下的用户层面

CDB和非CDB可以使用相同的管理工具

• SQL*PLUS
• SQL Developer
• ORACLE Enterprise Manager Cloud Control(Cloud Control)
• ORACLE Enterprise Manager Database Express(EM Express)
• Oracle Database Configuration Assistant(DBCA)
• Oracle Multitenant Self-Service Provisioning application

二，多租户架构的优势

非多租户架构面临的问题

一个大企业可能会使用成百上千个数据库。通常来说这些数据库会运行在多个物理服务器上，并且可能是不同平台的。

因为硬件技术的提升，尤其是CPUs数量的增长，服务器能够支撑更重的负载情况。这也就意味着一个数据库仅仅消耗了一台服务器的一小部分资源，也就浪费了大量的硬件和人力资源。

打个比方，100台服务器，每台服务器只有一个数据库，每个数据库占用10%的服务器硬件资源以及10%的管理员的时间，而一个团队的DBA需要单独管理每个数据库的SGA，数据库文件，账户，安全等等方面。

如下图，11个库，需要5个DBA，每人管理2到3个数据库。（吐槽，现在的DBA几乎不可能一个人只管理2到3个数据库，毕竟你的数据库不会经常出问题并且老是需要维护）

传统的处理方式是，

• 使用虚拟机来虚拟化硬件资源，单独管理数据库
• 一台服务器放多个数据库，虽然数据库是分离的，但是oracle元数据，后台进程和内存同样是分开的
• 逻辑分离数据到不同的Schema，这个方式其实有点类似多租户，但是在管理，安全和传输性上要差一点，并且需要应用设计配合

多租户架构的优势

推荐看一下这个油管视频，不知道能不能百度到：Oracle Database 12c: Introduction to a Multitenant Environment with Tom Kyte

https://www.youtube.com/watch?v=2MrouEW9j88&feature=youtu.be

常规数据库的合并会有以下类似的三种情况，多租户特性能够很好的解决这几个问题：

1，不同数据库使用相同的同义词

2，不同数据库使用相同的用户名

3，权限隔离，用户希望各自的DBA只能管理各自的数据

另外一方面，使用多租户特性的优势：

1，每个应用可以有自己的PDB

• 应用运行不需要改变
• 通过复制快速生成新PDB，迁移快速
• 可移植性，因为是插拔式的

2，在CDB级别的常规操作

• 不需要对多个PDB单独进行管理，比如说打补丁，升级，HA配置以及备份操作等，你对CDB的操作，相当于对所有插入到该CDB的PDB进行操作
• 也可以进行颗粒化管理

3，共享内存和后台进程

• 因为不需要像以往一样，每个DB都有各自的SGA/PGA，以及后台进程，就相当于节省了内存，每台服务器可以有更多的应用

新架构图：DBA少了，看起来更清晰一点

思考：如果CDB崩溃了，那所有PDB是否也会崩溃？如果是，对于生产环境来说，是否值得冒这个险来使用多租户特性？另外，多租户环境下，单个PDB的性能问题是否会影响到其他PDB？

使用多租户架构合并数据库有以下优势： 

• 成本降低

通过整合硬件以及数据库基础架构，仅仅使用一套后台进程，以及高效的共享运算和内存资源，可以减少硬件和维护的成本。比如说，在一台服务器上创建一个数据库实例，但插入100个PDB。

• 简单和快速地移动数据和代码

你可以使用plug或者unplug，把同一个PDB迁移到不同的CDB上，这种方式类似于表空间传输技术。

• 管理和监控物理数据库变得更容易

CDB管理员可以通过单一的操作来管理整个环境，比如说打补丁或者说RMAN BACKUP，是会对所有的PDB和root生效的。备份策略和灾难恢复是简化的。

• 分离数据和代码

尽管被整合成了一个物理数据库，PDB依旧对外表现的跟非CDB一样。比如说，一个PDB管理员可以在一个PDB环境里flush share pool或者buffer cache，并且不会影响到CDB里面的其他PDBs

• 管理权限的安全分离

一个用户如果是公共的，则可以连接到任意一个它有权限的容器，如果是本地的，则意味着它被限制只能连接到特定的PDB。

一个CDB管理员可以使用一个公共用户来管理PDB。一个PDB管理员则使用一个本地账号来管理各自的PDB。

因为权限只存在于它被授予的那个容器里面，也就是说，一个本地用户对同一个CDB里面的其他PDB没有权限的。

• 性能调优变得简单

收集单个数据库的性能指标要比多个DB环境简单，同样的，设置一个SGA大小要比设置100个SGA更简单。

• 支持使用ORACLE Databasae Resource Manager

在任何资源共享的环境，管理员必须管理系统资源，提供一个可预期的环境给用户，并且定位那些在预期之外的或者短暂的资源争用。

为了定位这些问题和提供资源使用率的监控，你可以使用Oracle Database Resource Manager

• 减少数据打补丁和升级次数

因为只需要应用在CDB上，不需要单独对每个PDB进行应用，所以要方便很多

使用多租户架构在管理方面的好处

多租户架构把数据和数据字典元数据存储在各自的PDB本身里而不是存储在同一个地方。

通过这种把数据字典元数据存储在PDB本身的方式，就可以把PDB当成一个单独的单元来维护，即便在CDB里面只有一个PDB。

分离开来存储数据字典的优势有：

• 迁移数据和代码更容易

比如说，如果你要升级一个PDB，你不需要升级CDB版本。可以选择创建一个更高版本的CDB，然后把PDB从现有的CDB上拔下来，然后插到新的CDB上面。

• 测试应用更容易

你可以在一个测试PDB上开发一个应用，然后当你要部署它的时候，把PDB拔下来插到生产环境上的CDB上面就可以了

三，数据库整合的方式

数据库在创建之后就决定了它是CDB或者非CDB。你不可以把一个非CDB转换成一个CDB，反之亦然。

你必须在创建的时候指定数据库为CDB，然后在创建完成之后再在CDB里面创建PDB和应用容器。

数据库整合的基本方式：

1，创建CDB

2，创建PDB

创建CDB

使用CREATE DATABASE ... ENABLE PLUGGABLE DATABASE来创建一个新的CDB。如果你没有指定ENABLE PLUGGABLE DATABASE，那么新创建的DB就是非CDB的，并且后续也不能转换。

在创建的过程中，除了root容器，即（CDB$ROOT）之外，oracle还会自动创建一个种子PDB（PDB$SEED）。

下图显示了新创建的CDB的结构：

 可以使用以下SQL来判断一个DB是不是CDB：

SELECT NAME, CDB, CON_ID FROM V$DATABASE;

NAME　　 CDB 　CON_ID
--------- 　　--- 　　----------
CDB1 　　YES 　　0

创建PDB

使用CREATE PLUGGABLE DATABASE来创建PDB。

这个PDB会自动包含全部的数据字典元数据以及系统创建的指向root的内部链接。你只可以在CDB里面创建PDB，而不能在PDB里面创建PDB。

下面这个图显示了创建PDB的选项：

下图显示了一个包含了6个PDB的CDB，hrpdb是新创建的PDB，salespdb是一个预先存在的PDB,是从其他CDB上拔下来插入到这个CDB上面的。

剩下的4个PDB，test*则都是从salespdb复制来的。

 从PDB$SEED创建一个PDB

这是CREATE PLUGGABLE DATABASE默认的创建方式，新的PDB就是从PDB$SEED拷贝过来的，如下图所示，它会把PDB$SEED的数据文件拷贝到一个新的地方。

例子： 

create pluggable database hrpdb admin user dba1 identified by password;

从PDB或者非CDB克隆一个PDB

可以使用create pulggable database语句来克隆一个PDB或者非CDB，然后把这个PDB插入到CDB上面。

克隆的来源可以是在本地或者远端的CDB里面的一个PDB。从12c R1开始，也可以是远端的非CDB数据库。这个技术会把source pdb或者非CDB的文件拷贝到一个新的环境，并且把这些拷贝来的文件和新的PDB关联起来。

注意：如果要从远端的CDB克隆数据库，需要用到db link。

下图显示了克隆的过程：

 如果基于的文件系统支持存储快照，那么你可以在克隆PDB的时候指定SNAPSHOT COPY语句来使用存储快照。

在这种情况，oracle数据库没有对源数据文件做一次完整的复制，而是创建了一个存储级别的快照，然后使用它来创建PDB克隆。

使用快照复制的克隆几乎是瞬间完成的。

以下SQL语句从PDB hrpdb克隆了一个数据库叫salespdb。

CREATE PLUGGABLE DATABASE salespdb FROM hrpdb；

通过插拔方式创建PDB

在非插入状态下，PDB是一个自包含的数据文件以及XML元数据文件的集合。

XML文件描述了PDB以及和它相关联的数据文件，插拔PDB就是使用XML来把PDB和CDB关联起来。

以下SQL语句基于XML文件里面存储的元数据，把financepdb插入到CDB上。

指定nocopy则表示不用重命名数据文件。

create pluggable databae salespdb using '/disk1/usr/financepdb.xml' NOCOPY;

用非CDB的数据库来创建PDB

你可以把非CDB的数据库转为一个PDB。

总共有以下几种实现办法：

• 在12c的非CDB数据库中运行DBMS_PDB.DESCRIBE

确认非CDB数据库是处于事务一致性的状态，然后运行DBMS_PDB.DESCRIBE函数来生成关于该数据库的xml元数据。

当连接到CDB的root容器的时候，就可以基于xml文件使用create pluggable database来创建PDB。最后，再登录到PDB，运行noncdb_to_pdb.sql脚本，把PDB数据字典中的定义转换为CDB$ROOT里相对应的对象。

• 使用Oracle Data Pump，使用或者不使用传输表空间的方式

你可以在非CDB的数据库上用Data Pump把数据集导出来，然后再把它导入到你想要的PDB里面，这种方式下，你的非CDB数据库的版本可以是12C之前的版本。

完整可传输导出会把创建一个完整数据库备份所需要的所有对象及其数据导出来。数据泵使用直接路径导出和外部表来导出对象，然后再使用直接路径插入和外部表来导入数据。

完整可传输dump文件包含了数据库的所有对象，不仅仅表相关的对象。完整可传输导出可以从11gR2导出然后导入到12C中。

• 使用Oracle GoldenGate复制

通过OGG来同步非CDB数据到PDB，当同步完后再切回PDB。

下图显示了使用DBMS_PDB.DESCRIBE的过程：