Overview of a few features in Oracle Pluggable Database 12c

By now, many of us have downloaded, installed and either played with or implemented the latest release of the Oracle Database.  If you haven’t downloaded the latest release, I would recommend that you do so and see what it has in store for not only your organization but also the industry as a whole.  Oracle Database 12c is going to… Continue Reading →

By now, many of us have downloaded, installed and either played with or implemented the latest release of the Oracle Database.  If you haven’t downloaded the latest release, I would recommend that you do so and see what it has in store for not only your organization but also the industry as a whole.  Oracle Database 12c is going to be an industry changer and a thought provoker with new and exciting opportunities.

Long before the official release of Oracle Database 12c, the initial announcement was made at Oracle Open World 2012.  This announcement started the buzz around pluggable databases and what exactly would it consist of.  I was at the initial announcement at Oracle Open World where the new term Pluggable Database or PDB was announced.  Initially, I was like how is this new architecture going to be different from Microsoft SQL Server?  As more information was released over the course of a year, the picture be came clearer on the purpose of Pluggable Database and Oracles approach to consolidation.

My opinion, the main driving factor behind Pluggable Database is the opportunity for consolidation.  Over the last decade, organizations have been seeking out opportunities to consolidate their environments.  Many of these consolidation efforts included moving to virtualized platforms like VMWare or Oracle Virtual Machines (OVM) at the operating system layer.  This consolidation did nothing for the databases.  Databases were still being resource intensive although hardware platforms were shrinking.

The question has to be asked, if organizations are consolidating hardware resources to virtual environments, how are the associated databases effected?  Organizations either move the databases as is to the virtual environments or opt to a single database with multiple schemas, hence database consolidation with security concerns.  Database consolidation with multiple schemas is one approach that can be used to shrink database footprints; however, this type of consolidation often leads to many different complex solutions to implement.

If database consolidation using multiple schemas is complex, what other options are there to consolidate a database environment?  Lets take a look at a few items that Oracle Database 12c provides for consolidation.


Consolidation of databases is one of the primary reasons to use the Pluggable Database option within Oracle Database 12c.  Pluggable Databases is really the term used to describe a type of database within Oracle Database 12c.  The concept however is really called Multi-Tenant databases.  When we start using multi-tenant databases, organizations can start shrinking their database footprint while shrinking their hardware footprint.

When talking about multi-tenant databases, we need to look at the architecture to understand how they work.  In order to use multi-tenant database, there has to be a primary container for the databases to plug into.  These container databases are called Container Databases or CDB for short.  CDBs can house 0 to N+1 multi-tenant (PDB) databases up to 252 on a single server.  Keep in mind; the 252 number is dependent on the size server the CDB and PDBs are running on. With the ability to now run N+1 PDBs on a single server, we can address the issues with database/schema consolidation.

As I mention earlier, database/schema consolidation can lead to complex solutions being developed when implemented.  With the use of PDBs, Oracle has removed these complex solutions by implementing a concept called Security by Separation.  This is simply implemented by creating N+1 PDBs and the users associated with each PDB are separate from the CDB and any additional PDBs.  By separating users between the CDB and PDBs, an organization can achieve a greater security centric approach to consolidation of databases while providing individual databases for applications.


Separating users by CDB and PDB is achieved by the definition of Common User versus Local User.  Within a CDB/PDB configured database, a Common User resides at the CDB level.  Common Users can access any PDB that is housed within the CDB.  In short, think of Common Users as super administrators within the database framework.  Oracle has made it easy to identify common users as well.  Common Users are required to have a prefix associated with them.  The default prefix for a Common User is C##.

Local Users are users that are local to either the CDB or PDB.  Local users do not have access to databases outside of the database where they are created.  There is no special prefix or requirements to create a local user.

In the example below, there are two commands for creating a user.  The create user command has changed, slightly, depending on the user that is being created.  A common user has to have the prefix discussed before along with the CONTAINER=ALL option. This enables the user to access all the associated containers within the CDB.  A local user also has the CONTAINER option.  Instead of using the ALL option, just need to provide the CURRENT option.

Processor Groups

Processor groups are used primarily for consolidation efforts with CDB/PDBs, Oracle has made it easier to assign processors to database instances.  Within Oracle Database 12c, we can now integrate the database with operating system processor groups. Processor groups allow us to bind a database instance to subset of CPUs on the server.   We can assign a processor group to a database instance by using the PROCESSOR_GROUP_NAME parameter in the spfile.

Within a Linux environment, a subset of CPUs can be created using a control group (cgroup).  In a Solaris environment, this is also achieved using resource pools.

Backup and Recovery

With any new release of the Oracle Database and/or consolidation process, a single question is always asked and answered.  How do we backup this new environment?  With the introduction of multi-tenant databases in Oracle Database 12c, backing up and recovering a PDB is critical to the availability of the database.  RMAN within Oracle Database 12c has introduced a new command to backup PDBs. This provided a new syntax option for RMAN; this option is PLUGGABLE DATABASE.

With the new enhancements to RMAN in Oracle Database 12c, a PDB can be recovered.  A point-in-time (P.I.T)  recovery of a PDB can be done from RMAN.

These enhancements to RMAN make RMAN still the best choice to backup and restore an Oracle Database.

Resource Plans

In previous releases of Oracle, the resource plan have always been available.  Not many organizations used them in the past though.  With the advent of consolidated databases (CDB) and multi-tenant (PDB) databases, resource plans are going to be not only needed but also an essential to resource consolidation.

A resource plan can be created on the CDB level and on the PDB level.   Creating a resource plan at the CDB level, you can allocate resources as needed to PDBs or distribute resources evenly across PDBs.

The features, which I have highlighted here, are only a small fraction of what was added or improved features within Oracle Database 12c.  The features discussed have a focus around what is available and used when looking at consolidating environments within the enterprise.  As with any new release of a product, it is good to test the new functionality before moving into production.


Twitter: @curtisbl
Blog: http://dbasolved.com