数据库整合
在一体机技术出现之前，通常情况下，一台服务器部署一套数据库，这种数据库部署方式实际上成本高昂，在一体机出现后，因其高性能/高可用以及良好的扩展性，将同一个机房中的多个服务器中的数据库安装部署在一台一体中的情况也较常见，这也是一种数据库整合方案，该方案虽然可以降低成本，但同时存在一些负面问题。
维护管理更加复杂
当我们将20套数据库部署到一台一体机中时，在20套数据库中辨识不同的数据库也会变的很头痛，显然会让维护变得更加困难，维护每套管理每套数据库任然有很大的挑战性。
资源隔离较困难
该整合方式中，如果其中某套数据库在某个时间点负载急剧增加，占用了绝大部分一体机资源，那势必会对其他数据库性能造成一定影响。内存资源我们可以通过数据库内部的SGA进行配置，CPU资源可以通过CPU_COUNT进行控制，但I/O资源又要如何进行管理呢？这种整合方式下我们很难做到对资源的细粒度的管理分配。
资源任然存在浪费情况
虽然在一定程度上做到了数据库的整合，但假如每个数据库后台启动20个进程，当我们同时部署20套数据库时，后台会同时启动400个相关进程，同样的进程Oracle为每套数据库分别启动一个，显然冗余，在资源上也造成一定的浪费。
基于12c中容器的数据库整合
在12C中，Oracle推出了容器数据库，通过容器的方式对数据库进行整合后，可以对上面的问题进行完美的解决。
资源被合理利用
在Oracle 12c中当，我们把20套数据库以PDB的方式插入到CDB中，因其PDB共享CDB的后台进程，后台只会启动20个进程，并不会因为我数据库的增加，后台进程也随之增加。
在资源方面我们可以节省更多的资源，更加有效的对资源进行利用，同样配置的一体机中，当使用容器的方式进行整合后，可以部署更多的数据库。
资源管理更加灵活
当数据库以PDB的方式插入到CDB中时，资源管理变得更加灵活，可以更加细粒度的根据每个PDB的需求情况为每个PDB数据库配置不同的资源，以及限制PDB对资源的过多使用，可以达到避免因为某个数据库使用过多的资源而影响其他数据库。
- I/O资源隔离
- MAX_IOPS/MAX_MBPS
- 内存资源隔离
- SGA_TARGET/SGA_MIN_SIZE
- CPU资源隔离
- CDB resource plans
- 存储资源隔离
- flex diskgroup
当某个PDB随着时间的推移它的业务量也不断的增加，需要更多资源的时候，我可以非常灵活的修个相关参数动态的为他分配更多的资源。
降低维护成本
整合后，在维护上我们也可以降低维护成本，之前我需要分别去维护20个不同的数据库，那整合后我们只需要将20个库作为一个CDB数据库进行统一管理。
备份：在不做整合时，20套数据库需要我们维护20个不同的备份任务，现在我们只需要在CDB级别进行统一备份就可以完成对20个PDB数据库的备份。
DG：整合后只需要搭建一套DG环境就可以，不需要为单独为每个数据库都去搭建一个备库。
升级维护：在升级方面，整合后我们只需要对一个CDB进行升级，就可以完成CDB中所有PDB数据库的升级，如果想对其中一个PDB进行升级，我们也可以通过克隆或者移动的方式，将他移动到更高版本的CDB中，这样就可以做到对某一个PDB进行升级。
更好的一个升级方式。我可以在一体机中在安装配置一个更高版本的CDB，然后直接把低版本CDB中的PDB拔出，插入到高版本的CDB中，同样也可以完成升级工作。可能之前一套数据库升级要花费2个小时的时间，那现在我们可能10分钟就升级完成20套数据库。
整合时需要思考的问题
任何事情都是两面性的，虽然整合可以为我们带来很多的好处，但同时也会带来一些其他问题。
1.当一体机出现问题时，一起一体机中部署了更多的数据库，那我们所有的PDB都会受到牵连。这个问题我们要如何去避免呢？
另外，CDB层面出现了不可以修复的问题，我们又该如何去解决呢？
2.因每个PDB均是来自不同的业务，当我们在做相关维护时，比如一体机的维护或者是CDB级别的维护，我们把所有PDB的维护窗口协调在同一个时间段，其实该问题同样较困难。
