Basics of Multitenant Architecture and Pluggable Databases in Oracle 12c
One of the most talked about new features of Oracle 12c is multitenant databases. They have also come to be known as pluggable databases. If you haven’t heard about the cloud, you must have been living under a rock for the past several years. The c in 12c stands for cloud.
Serving up computing resources and applications in the cloud is all the rage these days. Doing so reduces capital expenditures for corporations and has immediate tax benefits as well. Therefore, companies have a lot of incentive to take advantage of cloud computing.
One of the technologies that has really taken off with the cloud computing revolution is virtualization. Using virtual machines carved out of larger physical machines and leveraging fractional licensing further reduces costs for corporations. Oracle multitenant databases were developed to help companies take advantage of all these technologies and cost savings.
The Multitenant option of Oracle 12c is licensed. As usual, check with your Oracle sales rep for costs. Again, though, make sure you’re aware of the return on investment that this feature can bring you.
You need to be aware of the new types of databases that are now part of a multitenant architecture:
Container Database (CDB): The primary database that contains multiple plugged-in databases. Many operations can be performed at the container level to reduce management costs. A database is created as either a CDB or a non-CDB.
Pluggable Database (PDB): A set of schemas, objects, and non-schema objects that can be plugged and unplugged from a container database. The PDB appears to OracleNet and end users as a database in and of itself but is actually managed within a container that may have many PDBs.
Seed Database (Seed PDB): A default PDB that the system uses as a template to quickly provision other user-created PDBs. Internally, it’s called PDB$SEED.
The Multitenant option helps you accomplish the following:
High consolidation density: Many databases can share memory and background processes.
Provisioning: A database can be unplugged from one environment and plugged into another or cloned with SQL commands in just a few seconds. They can even be plugged across operating systems and chipsets.
Patching and upgrades: You can patch a database simply by unplugging from one unpatched container and plugging it into another patched container.
Manage many databases as one: You can do tasks such as backing up and patching on the primary container database instead of the individual pluggable databases.
Resource management: The Oracle Resource Manager feature can work at the pluggable database level for you to manage resource competition among the databases in your environment.
One other thing worth mentioning is that a pluggable database is fully compatible with a non-CDB. In fact, Oracle has something it is calling the PDB/non-CDB compatibility guarantee, which states that anything you would do in a non-CDB would also work in a PDB. This compatibility guarantee is important when it comes to certifying things like third-party vendor products to work in a multitenant architecture.
How to create a multitenant database environment in Oracle 12c
When creating a database, you must designate it as a CDB or non-CDB for it to be able to support the multitenant architecture. The next set of examples walks you through the steps to create a container database with the DBCA. There is only one step that differentiates a CDB from a non-CDB when using the DBCA.
Following the advanced path of creating a database, the first thing you may notice is a check box for Create As Container Database on Step 4 of 13.
You also can choose the number of PDBs created at this time. You can also choose to create an empty container database with no pluggable databases at the onset. The rest of the steps are pretty much the same as when you create a non-CDB.
How to start and stop pluggable databases in Oracle 12c
Because the instance architecture of pluggable databases is entirely different from a non-container database, one would imagine that managing their state of readiness is also different. Well, it’s true. Let’s start by looking at the CDB itself.
The first thing to remember is that because the CDB maintains the instance for which all PDBs share, that instance must be up and open for people to be able to connect to the PDBs. Starting and stopping the CDB is not different from non-CDBs.
The next thing to remember is that when you start a CDB, all of its associated PDBs are left in MOUNT state, which means that, by default, they are not opened with the CDB. Unfortunately, 12cR1 doesn’t offer an option to change this behavior.
However, 12c does provide a new type of trigger that will fire if it detects a CDB opening and will then open specified PDBs. See the Oracle documentation for further information on setting this up.
After starting and opening a CDB, you can open any corresponding PDBs like so:
SQL> alter pluggable database devpdb1 open; Pluggable database altered.
SQL> alter pluggable database all open; Pluggable database altered.
To close PDBs, you can essentially do the opposite of the preceding commands:
SQL> alter pluggable database devpdb1 close; Pluggable database altered.
SQL> alter pluggable database all close; Pluggable database altered.
You can use the V$PDBS data dictionary view to get information on the readiness of the PDBs.