Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 226

The non-CDB, or any other Oracle database before 12.1 for that matter did not have any facility to separate
applications in the same way as a container database has. As you know, the super-users in all releases prior to 12.1 had
full visibility of all the data stored in the database. The only way around this was the use of Data Vault or comparable
solutions. Although they certainly helped achieve the goal of preserving privacy in realms, they had to be configured
and maintenance operations affecting the whole database were somewhat complex to arrange and perform. It is the
author's firm belief that complexity is the enemy of successful database operations these days. If something can be
simplified, it should be.
The CDB however is a container for multiple Pluggable Databases, without much of the previously required
manual configuration. The all-powerful user accounts however can still connect to a PDB quite easily and view
data. Without additional configuration however powerful users defined locally in a PDB cannot query information
in another PDB. Sensitive environments should still employ additional layers of protection within the Pluggable
Database.
Each Pluggable Database is completely self-contained from a user data point-of-view. All user data that makes
up a database can safely be stored in a Pluggable Database without the risk of compromising compatibility. The
Pluggable Database can easily be moved from one Container Database to another. The PDBs and CDB$ROOT share
the data dictionary. Not all dictionary information is duplicated in each PDB—that would be a waste of space. Instead
a PDB facilitates pointers to the dictionary of its container database's root. Whether or not an object in the database is
shared can be seen in some views, including DBA_OBJECTS. A new column, called SHARING, indicates if the object is
a metadata link to an object in the root, or an object link, or none of the two.
This greatly increases flexibility, and is a main differentiator to other consolidation approaches where each
application is hosted in a dedicated database—which needs patching of the data dictionary. With a CDB you can
potentially patch hundreds of PDBs for the price of one. This chapter will provide you with an overview of how to
unplug/plug a PDB from one Container Database to another.
In order to create a Container Database, the DBA has to make a conscious decision at the creation time—the
Database Configuration Assistant provides an option to create the new database as a CDB. It is important to note at
this point that a non-CDB cannot be converted into a CDB. Instead, it has to be converted to a PDB which in turn can
be plugged into an existing CDB. We will see that this is necessary during migrations, which are detailed in Chapter 12.
The CDB creation required an enhancement to the “create database statement,” but the scripts to be run to create
a custom database have changed in comparison with the non-CDB case. See further down in the section “Creating a
CDB using scripts” for more information on how to create a CDB from the command line.
The documentation has been updated in many places for the new Pluggable Databases Feature. Additional
information about PDBs and the new structure can be found in the following topics of the official documentation set:

• Concepts Guide

• Administrator's Guide

• SQL Language Reference

• Security Guide

• Backup and Recovery User's Guide

• Data Guard Concepts and Administration

• And there are references in many others more

I personally like to keep bookmarks for these in my browser under a special “Oracle 12.1” category. I have
been involved in a number of discussions about consolidation projects, and all of these mentioned at one point or
another about the difficulties using Oracle before 12.1 to find a consensus between the engineers and the operational
DBAs. Great technology is certainly of a lot of academic value, but if the level one and level two support simply
cannot support from day one, it is a lot of time and money wasted. It once again comes down to skill, and sadly skill
often weighs less than cost per hour. With Oracle 12.1 a good balance can be reached between new technology and
operational maintenance procedures.