Home » ORACLE » DATABASE OPTIONS » Oracle 12c Multitenant Option – A Database Architect’s Perspective

Oracle 12c Multitenant Option – A Database Architect’s Perspective

The Future

Do you wonder what the future holds for the principal Oracle Database platform in terms of its RDBMS Architecture? The Oracle Multitenant Architecture is the platform for the future.

Putting this plainly, the current Non-Multitenant Architecture (aka Legacy Architecture), will ultimately be de-supported so, if you’re serious as an Oracle DBA, you had best get on board! But rest easy for now; the 12cR1 Oracle Database release still supports both the Multitenant and legacy configurations.

Key Features

Just in case you were still wondering what its all about and have not dug in and tried to decipher the multitude and sprawl of information out there via a quick google search, here is a quick heads-up on the key elements of the Multitenant architecture you need to be aware of.

The Multitenant option is only available on Oracle 12c with a database COMPATIBLE parameter of or greater. This value also applies to each planned Pluggable Database (PDB) being deployed within it.

You can run Oracle Container Databases (CDBs) and Non-CDBs on the same Server and can even share the same ORACLE_HOME.

A Multitenant database provides the capability of a Database to act as a CDB. There are two potential configurations:

  • One type of Container Database can act as a singularly unique database which can be plugged into another Container Database. This is called a Pluggable Database (PDB) and it contains all the usual object types you would find in a standard legacy database.
  • The other type of Container Database can contain none, one or more unique Databases (PDBs) and is called the CDB. A CDB consists of a root container as well as a seed PDB database which is READ ONLY by default.

Then again, you can find this information anywhere, the question is what are the key Architectural considerations you need to focus on as a DBA?

Structural Differences

Essentially, we need to first look at the structural differences between the Legacy and Multitenant architectures.

A container database can exist on its own with or without additional PDBs. Putting aside RAC Architectures, a legacy Oracle database is by design associated with one Oracle instance. In the same context, an Oracle CDB (multitenant Container Database) is associated with one instance. Therefore you have a 1:1 relationship between a database and instance.

However, a key variant for the Container database Architecture is that the CDB and all its associated PDBs “share the same Oracle Instance.” Hence you have a many to one (n:1) database to Oracle Instance relationship

  • n = CDB and all its associated PDBs

In the context of Oracle High Availability RAC architectures, the same statement would translate to an Oracle Database being associated with “one or more Oracle Instances”. Hence an Oracle CDB (and its associated PDBs) is associated with one or more RAC instances in an n: m relationship

  • n = CBD and all its associated PDBs
  • m= Oracle Instance(s) belong to the same RAC infrastructure

Hence in a multitenant environment for one CDB with a relationship to one or more PDBs, we have the following commonshared entities residing in the root Container:

  • SGA Memory Structures
  • Control files (at least one)
  • Background processes
  • Online Redo logs
  • Oracle Wallet
  • Alert Log
  • Flashback logs
  • Archived Redo logs
  • Undo tablespace and its associated Tempfiles
  • Default Database Temp Tablespace and files (however, each PDB can also have its separate Temp Tablespace)

The Oracle Data Dictionary metadata is principally stored in the root container at the CDB level with links for each PDB dictionary object defined to this from the PDB.

Deployment Architectural considerations and benefits

If you need to deploy a CDB with multiple PDBs and are wondering what you need to consider and how you optimize these, while not a complete list of review points, some items for considerations are

  • Adequate PDB unique names which translate into Services names for access
  • Resource management and delineation against each PDBs for resource consumption
  • Sizing and impact of each PDB on the shared Redo Logs, Temp Tablespace and Undo tablespaces
  • Understanding that all Oracle upgrades are performed at the CDB level and impact all associated PDBs
  • Strategy to leverage new security features related to separation of users and responsibilities between and across the CDBs and PDBs
  • Strategy for consolidated performance tuning
  • Communication to the business of the benefits of reduced cost of platform and ease of platform management
  • Plan for consolidation, especially for same version databases with small storage and memory footprints
  • Consideration for Oracle DataGuard configuration for related PDBs

Limitations and Restrictions

In spite of all the benefits, you know what they say. With every good thing comes …  Below are also a few restrictions (relative to the known operations of the legacy Databases) for RMAN on PDBs:

RMAN Restrictions from PDBs

  • Tablespace point in Time recovery
  • Duplicate Database
  • Point in Time recovery
  • Flashback operations from RMAN
  • Table recovery


So now you have the basics of what you need to be aware of, and to explore from an architectural standpoint. You can now dig into each section to obtain more information and see how to further optimize within the context of your requirements, resource availability and deployments to meet with your planned application needs.

At Cintra, as Database Architects, these are just a subset of the kind of considerations we delve into when looking at deploying customer databases. Get in touch if you would like to discuss how the Multitenant Option might be of value to your business.

Written by Joseph Akpovi, Lead DBA, Cintra NY – May 2017

© This website and its content is copyright of © Cintra Software and Services 2011. All rights reserved.