Blog | Dec 4, 2014
Oracle 12c for Pro Newbies: Pluggable Database Architecture
When you ask your colleague, “Hey, do you know what features Oracle 12c database has?” He says, “I don’t know much, but I heard some Pluggable Database concept is there.” You are surprised to hear the words “Pluggable Database! What’s that? Maybe it’s the additional functionality I want to learn now!” This blog will help in understanding the concept of Pluggable Databases for a Pro Newbie 12c DBA.
Pluggable Database as the name suggests, ensures flexibility to be plugged in from one machine to the other, and if you have seen any pictures of 12c database, you may have noticed the USB drives representing the pluggable database plugged into a machine. With Oracle 12c, you can plug your database into one server, then unplug it and move it to another server without any major trouble just like you would do with a USB drive. Yes, that is the extent of the flexibility that Oracle is providing with these pluggable databases.
If you have read some of Oracle’s cloud computing articles then I am sure you are familiar with the term “multitenancy”. Oracle wasn’t initially in support of cloud computing or the multitenancy concept due to some of the security related issues, however as the cloud has caught on Oracle had to jump on board also. Multitenancy is the term guiding the architecture of the pluggable databases and cloud computing.
To clarify what we mean by specific terms, I would like to clarify a few: “Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client-organizations (tenants).” - Wikipedia
Pluggable Databases and the multitenant architecture:
In Pluggable Database architecture of Oracle 12c, we have one instance (a set of memory and background processes) serving one or more than one databases. Until 11gR2, there was one instance associated with only one database, but in a pluggable database architecture, an instance may be associated with hundreds of databases depending on the requirements of the client and specifications of the machine.
Look at the figure below, there is a cuboidal box called the root (CDB$ROOT where CDB stands for Container Database). Note that all databases before Oracle 12c were Non-CDB type databases. This container database provides the space for plugging in the pluggable databases (PDBs). The container database serves the instance for all the pluggable databases attached to it. It also contains the metadata for managing all the pluggable databases.
There are three main components to this architecture. Each of these three components is called a container and has a container ID within the CDB (Container Database).
i. CDB$ROOT: This is the root container and is responsible for managing all the metadata for pluggable databases. It also serves as a common instance providing all the memory and background processes to the parasite databases attached to it.
ii. PDB$SEED: It is a read-only database which is used to create new databases. It serves as a base model for the enterprise pluggable databases.
iii. PDBs (Pluggable Databases): These are the actual client databases which appear similar to non-CDBs of the past. These work in the similar way except being the owner of the instance. If you are inside any one of these PDBs, none of the other PDBs is visible to you. This provides a level of security for the data as one application database is separated from the other application database. In point. (i), I referred to these as “parasite databases”. It is because these databases feed on the CDB for all the memory resources.
Image Source: Oracle Docs (https://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm#CNCPT89245)
All the PDBs can be managed and served from one CDB thus satisfying the definition of multitenancy. This reduces the costs of managing all the non-CDBs individually since a smaller number of physical and human resources will be required to manage and support one database (CDB) against 100 databases in case of the non-CDBs.
Please note that each pluggable database has its own set of data files. These can be managed in the same way as a non-CDB from within the PDB. You are able to engage one DBA manage all of the PDBs from the CDB or individual DBAs managing from within the PDBs.
E.g. you can take a backup of a single PDB from within the PDB or all the PDBs from the CDB. This ensures data-separation.
A single instance (memory and background processes) and single redo log is provided by the CDB for all the PDBs in the case of a Non-RAC architecture. There is only a single undo table space per CDB in all non-RAC designs. As of now, you can create and administer a maximum of 235 PDBs (seed included) from within a CDB.
You can exploit the concept of multitenancy while upgrading and patching the databases by patching/upgrading one CDB and pushing the same to all the pluggable databases, thus saving maintenance time.
In the upcoming posts, you’ll learn how to create a CDB and the associated PDBs. Stay tuned to learn more!