Introduction to Oracle 12c Multitenant Database - Part 1

Up until 12c, Oracle database had one instance can work with only one database (barring RAC - Real Application Clusters; multiple instances share one single physical database). Before we look at what 12c is, let's try to understand why one instance - one database approach is not optimal with the current advances in hardware and software. Usually in an organization, for different applications, one or more databases are used. Often, these databases run on multiple physical servers, possibly in different operating systems. Usually one database instance per one server. The servers are grossly underutilized. What can we do about it?

Figure: Oracle legacy database (11g and before) - one-to-one mapping

One possible solution is to run multiple instances-databases in the same server. It works to some extent to support a few database instances per machine, but the approach still is not so efficient in terms of resource utilization. The reason is that multiple instances do not share background processes, system/process memory or Oracle meta-data. Further, it is difficult to management many database instances given the fact that some organizations deploy thousands of them. This naturally leads to the question whether we can create a shared resource architecture to support multiple instances.

Figure: Oracle legacy database - each application uses multiple database instances (source: http://goo.gl/HznYKe)

Another possible solution is to isolate database files for different applications using a virtual private database (VPD); that way we do not have duplicate background processes, system/process memory or Oracle meta-data. However, it is difficult manage security, isolation, and transport data in VPD.

Having seen the pros and cons of the above two approaches, it is logical think if we can combine the best of both and create a better database system. Yes, you guessed right, that's exactly what Oracle 12c (c stands for cloud) has done! Oracle 12c is called CDB (Container Database) or Pluggable Database.

CDB consists of two levels. A root container called CDB$ROOT and one or more pluggable databases PDBs. A PDB is very similar to a legacy database except that it shares background processes, memory and meta-data with other PDBs. Unlike VPD based solution, at the same time, it provides stronger security and isolation controls, and further easier provisioning via cloning and portability via pluggable feature.

Figure: The same legacy deployment with new CDB - consolidated to one machine (source: http://goo.gl/HznYKe)

Think like a USB device to be a PDB and computers with USB ports as CDB container. Once the CDB$ROOT is up and running, you can plug in any number of PDBs to the CDB. There is a seed PDB called PDB$CDB which you can use to clone new PDBs. You can move (plug/unplug) PDBs between CDBs.  

Figure: CDB - Multitentant architecture

We will look further into the CDB concepts in the next blog post.