Oracle Database 12c中带来一种全新的架构，允许用户在一个独立的Oracle数据库中拥有多个pluggable可拔插的数据库。这种Pluggable 可拔插数据库的出现是为了对应 用户目前使用RDBMS数据库的现状，即有一些用户拥有大量的部门级应用构建于Oracle RDBMS数据库之上。
上图给出了一个Container Database 并带有4个Containers， ROOT(CDB$ROOT)和其他的三个pluggable Database。每一个Pluggable Database均拥有自己的独立应用程序，这些Pluggable Database要么有自己的DBA， 要么被Container Administrator即SYS用户管理；SYS用户属于root(CDB$ROOT) Container 是一个common user。 SYS用户还是像之前的版本那样权威，他可以管理root container 和其他所有的pluggable database。 一个Pluggable Database可拔插数据库是 一堆database schemas数据库模式的集合以一个分离的数据库逻辑形象呈现给用户和应用程序。但是在物理级别，Container database拥有一个数据库实例以及多个数据文件，和普通的非CDB是一样的。 不管是客户端程序还是数据库对象均无需修改，以适应CDB。 用户将很方便地将一个非CDB 插入到一个CDB中， CDB避免了以下的冗余：
关于CDB 数据字典实际情况的测试： 通过下面的实验我们可以得出如下结论：
以下几个场景适合于使用pluggable database:
- 在产品系统中的某些应用实际仅使用十分少量的硬件资源。但是如果存在大量这样的应用，则还是需要构造大量的数据库实例并为这些小规模的数据库分配存储空间
- 对于那些并不十分复杂或重要，需要全职DBA花费大量时间管理的数据库
- 为了更好地利用硬件和DBA资源，用户有必要将大量的部门级应用整合到少数几个oracle RDBMS数据库中以便部署和管理
Pluggable Database 带来的好处
在一个集中化的平台上操作多个数据库将有效降低成本：- 更少的实例损耗
- 更低的存储成本
- 无需应用修改
- 更快和简便的配置
- 节省了打patch和升级的时间
- 分离了以下责任：
- 不同应用的管理员
- 应用程序管理员和DBA
- 应用用户
- 提供isolation
- 保证与非CDB 完整的向后兼容性
- 完整的RAC操作使用
- 与Oracle Enterprise Manager和Resource Manager整合在一起
- 可以集中化管理多个数据库
- 备份和灾难恢复
- 补丁和升级
上图给出了一个Container Database 并带有4个Containers， ROOT(CDB$ROOT)和其他的三个pluggable Database。每一个Pluggable Database均拥有自己的独立应用程序，这些Pluggable Database要么有自己的DBA， 要么被Container Administrator即SYS用户管理；SYS用户属于root(CDB$ROOT) Container 是一个common user。 SYS用户还是像之前的版本那样权威，他可以管理root container 和其他所有的pluggable database。 一个Pluggable Database可拔插数据库是 一堆database schemas数据库模式的集合以一个分离的数据库逻辑形象呈现给用户和应用程序。但是在物理级别，Container database拥有一个数据库实例以及多个数据文件，和普通的非CDB是一样的。 不管是客户端程序还是数据库对象均无需修改，以适应CDB。 用户将很方便地将一个非CDB 插入到一个CDB中， CDB避免了以下的冗余：
- 后台进程
- 内存分配
- 多分数据字典源数据
关于CDB 数据字典实际情况的测试： 通过下面的实验我们可以得出如下结论：
- 每一个Container 维护自己的一套底层数据字典 数据实际存放在C_OBJ#(C_OBJ#
本文转自maclean_007 51CTO博客，原文链接:http://blog.51cto.com/maclean/p2
