Oracle Database 12c: New Features – Pluggable Databases by Michael Rajendran

Introduction

Oracle has leap forwarded the middleware technologies especially the database technology into the cloud. So far Oracle has been the traditional RDBMS database suitable for the private enterprise data centers within corporate walls. In Oracle Open World 2012 held in San Francisco, Larry Ellison announced that oracle database also be cloud enabled by introducing pluggable databases for multi-tenancy and easy database movement between systems, platforms or releases. When the database is a cloud ready, it should be hardware agnostic, platform agnostic and release agnostic so that it gives all the characteristics to be in Platform as a Service (PaaS) for middleware. It is a brand new capability insider a single container database. So the DBAs and developer community should be familiar with “Container Databases” or CDB and “Pluggable Database” or PDB. I will refer PDB and CDB to refer pluggable database and container database respectively.

Multi-Tenancy

Before we delve into deeper details about CDB and PDB, let us get some basic details about multi-tenancy. Most of the organizations use the multi-tenancy with application level logic i.e. multiple customer or different entities data within the same database. They can be setup with many different schemas or even within a schema. But managing the security has lot of caveats including auditing as Larry Ellison & Andrew Mendelsohn mentioned on their respective keynote addresses. It has been an administrative nightmare when multiple databases are running in one machine. The backups need to be run separately. Each database has memory footprint and each database has background processes. This increases the capacity of the server on what it can handle in terms of the loads. By consolidating into one container database and at the same time keeping all of them as separate databases are a great thing from consolidation, performance, capacity and operational perspective. This is going to help in a very big way for consolidation on many enterprises and at the same time it will reduce the server footprint significantly giving the maximum Return on Investments (ROI) on the middleware database technologies. I really think this new feature has lot of advantages from small customers to large scale enterprise customers no matter how we look at it. It is going to make the enterprises to become smarter in terms of utilizing the compute capacity what they have.

CDB vs. PDB

CDB is an acronym for “Container Database” and PDB is an acronym for “Pluggable Database”. I think it will be easier to explain with a metaphor for DBAs. Think of a freight train with many cars up to 250. Each container could be having different contents, with delivery target for different customers and completely packed/sealed independently with customer options but the entire freight is carried by a single engine or carrier at the front. It will be stupid enough to run 250 freight trucks but rather it is efficient to consolidate them into a single freight train. When running independently we will spend on gas, drivers’ expenses and much more complicated to manage them. The freight train is basically the CDB and each car is the PDB.

PDB is fully backward compatible to pre-12.1 database releases. There is nothing different from a developer or application connectivity perspective. Everything stays the same but the PDB will belong to a single CDB. When application connects to the PDB, it will specify the destination PDB via a database service. All home-grown or third party applications typically will have connectivity defined out of the application so it is easier to just change the service name outside of the application code. So all database connectivity should use “database service” rather than using the legacy approach of ORACLE_SID based connectivity. ORACLE_SID ties the application connectivity to a specific database instance and does not give the scalability or high availability. You can have many pluggable databases in 12.1.

Architecture & Features

Split Data Dictionary

You might be already asking the question on how the data dictionary is managed for the CDB as well as for all the PDBs. That is where the architecture of CDB dictionary (or catalog) and PDBs dictionary come into picture. Oracle calls it as a “root” namespace where the CDB belongs. This will have an “Oracle System” dictionary which will be provided by Oracle in new releases and/or in patches. This will be exclusively controlled by Oracle. Each PDB will have its own dictionary or metadata which are owned by the customers. Each PDB dictionary defines its own namespace. Each PDB will also have the “read only” copy of Oracle dictionary as well. We can call it as a “Split Data Dictionary” architecture which enables the PDB to keep its own dictionary and makes it easy to be portable between multiple CDBs. Each PDB is a self contained system, a clear declarative definition of an application, which knows nothing about the next PDB within the CDB. Each PDB is a sealed container in a 250 freight container train or CDB as I explained before.

Compatible: RAC, Resource Manager etc

Each RAC instance opens the CDB as a whole so that versions would be same for CDB as well as for all of the PDBs. PDBs are also fully compatible with RAC. Pluggable database is if fully compatible with all the database options and features including resource manager. Resource Manager is extended for creating, unplugging, plugging in, and cloning, dropping or even setting up for the open mode of the PDB.

New Administrator: CDB Administrator

A new administrator has been introduced in 12.1 release databases. The new admin role is “CDB Administrator”. CDB administrator will login into the new concept of “CDB root” namespace. There are several commands which can be executed from the CDB root and all commands, which were working in pre-12.1 databases, are all compatible in a PDB.  You can use one of the several commands to find out which container currently you are logged in.

Unplug and Plug PDB

What is more? You can plug out (unplug) a database from one container database and then plug in into another container database. This is pretty cool feature. This could be useful in many situations.

·         Migrating databases to new platform

·         Migrating databases to new hardware

·         Migrating databases to new DB releases

·         Moving databases to different systems

·         Enhancing high availability of databases by moving between systems

There are much more new features which are introduced to make the database completely agnostic to the hardware system, platform or releases. For an example “Application Continuity” which even connects to the database even if the database was restarted and the application would connect without failing by replaying the last failed transaction including DML. This will be explained in a separate article so please look for that article.

Faster Provisioning, Patching & Upgrades

You can clone a PDB within the same CDB or into another CDB. PDBs can also be provisioned very fast as each CDB comes with a “PDB Seed” from where the new PDB can be fast provisioned. So the provisioning becomes very fast.

Redeployment becomes much easier as we can unplug the database from one platform or a CDB version and then plug it into a CDB which is in another platform or version. This will make the upgrade, patching and redeployment efforts much faster! When you upgrade the CDB, all the PDBs will get upgraded. If you would like to control when the PDBs should be upgraded, you can create another CDB version and then unplug from the old release and then plug in to the new database release. All PDB contents are separate from each other PDB so the “separation of duties” works very well as well.

Database Administration & Granularity Control

Database administration becomes easier as CDB can be managed as a whole such as backup using RMAN, setting up disaster recovery using Data Guard etc. However you can also backup selected PDB if you choose to do so. You can also restore and recover a PDB to point in time giving separate recoverability at the PDB level by connecting to the root (CDB) or at the PDB level. When you add a PDB, it will take care of the Data Guard configuration for that PDB.

You want to do in a single operation such as backup, data guard setup, recovery, patching, upgrade etc or you want to do granular management such as recovering a PDB only, migrating / patching a PDB on its own schedule etc.  When you want to patch and you want to control when each PDB is getting patched, then you create a CDB for the new version or patch and then unplug/plug the PDB whenever the PDB is ready to be migrated. It is that easy with complete control.

Unique Service Names for PDBs

A service is created and started inside a PDB that identifies it as the initial container even though the metadata is stored separately for that PDB. But the service is unique across the CDB.  Please note that the sessions are created by authorizing as a user that cannot change the current container.  You should ensure the services within a container are unique. In fact you should have the unique services registered on a listener. I recommend using a unique service across the entire cluster. Creating services, dropping or maintaining a service within a PDB is nothing different than what we have been doing in pre-12.1 releases.  As I mentioned that each PDB comes with a default service which cannot be dropped. The only way to connect to a PDB (whose initial container is a PDB) is by using a service.

Pluggable Databases Examples

Create PDB

Now let us look at some examples to create the PDB. In this example let us assume we have a container database for “Investment Banking” called CDB01P. We will create a PDB database within that container database.

·         Connect to the container database

·         Create the pluggable database

·         Check the pluggable database

It was intentionally shown the pluggable database creation time to find out how fast the database can be deployed.  It took less than a minute to create a new PDB. Typically DBA takes time to create the database. Even if the infrastructure is ready, still the DBA can be spending 2 hours to half a day to provision a new database. Now that time can be wisely spent to understand the application or help tuning the SQLs to better improve the performance of the application. The database deployment can be automated and you can give an option to self provision the database really quick.  Every container has a PDB seed database which has SYSTEM and SYSAUX tablespaces from where the DB build is copied to provision a new PDB. The example shown is based on a file system based database but you can use it with ASM as well as PDB is fully compatible with RAC and ASM.

Drop PDB

You can drop the PDB using a simple command. As DBAs are familiar with database commands, this command should NOT be a surprise. The syntaxes are fully in-line with existing syntaxes.

Convert Non-CDB to PDB

We can convert a non-CDB database to a PDB into a container. There are few steps involved as listed below.

·         Ensure the non-cdb can be opened in the 12.1 release

·         Close the non-cdb

·         Open the non-cdb in restricted mode

·         Set the container to itself (as initial container would be itself)

·         Run an oracle script to convert

Clone a PDB

Oracle offers two types of cloning. The first option is shown in the example commands below and this can be used for fast provisioning with the same CDB or into another CDB. Oracle also offers another option to clone database on file systems which can work on “Copy On Write” technologies such as ZFS file systems or NetApp NAS file systems. The cloning will be done in few seconds and it will be much more useful in non-production environments.

Unplug and Plug PDB

Oracle offers to unplug a PDB from one CDB and then plug into a different CDB. This will be another additional feature of PDB to give the highest availability and scalability the database systems may need in a cloud infrastructure environment.  

Conclusion

Oracle Database 12c offers the pluggable databases which are extremely useful to run a cloud database environment whether that database runs in Oracle’s Public Cloud, Oracle Internal Cloud behind corporate firewalls or even customer owned discrete infrastructure with 12.1 clusters. Oracle Database 12c is completely platform agnostic which makes it as unique first RDBMS with ACID compliance which makes no difference between the version runs in the cloud as well as in private data centers.

References 

·         Larry Ellison, CEO, Oracle: Oracle Open World Welcome Keynote: Oracle and Fujitsu

·         Andrew Mendelsohn, Senior VP, Database Server Technologies, Oracle: General Session: What’s next for Oracle Databases?

·         Bryn Llewellyn, Distinguished Product Manager, Oracle & Kumar Rajamani, Architect, Oracle: Consolidating Databases with Latest Generation of Database Technology  

Author

Michael Rajendran, an Oracle Certified Master, is working with database technologies for more than 16 years in Manufacturing, Telecom and Financial industries. Michael has experience in architecting, designing, deploying and managing extremely mission critical systems. Michael has also much experience in various aspects of cloud computing especially infrastructure, platform and software services and regularly writes on www.unbreakablecloud.com. Michael can be reached at mikerajendran@gmail.com. 

Disclaimer

The above document is intended to outline Oracle’s general product direction based on the information compiled from the references listed. It is intended for information purposes only for learning. The development and release of these functions including the release dates remain at the sole discretion of Oracle and no documentation is available at the time of this writing. The command shown may or may not be accurate when the final database release goes GA. Please refer Oracle documentation when it becomes available.