Database Reference
In-Depth Information
Chapter 7
Pluggable Database Primer
This chapter is designed as a quick “how-to” describing what pluggable databases are, why they have been introduced
in the form of multi-tenancy, and how to use them in terms of practically navigating their structure. This practical
implementation material will help you to test and understand the security issues regarding 12c in the forthcoming
security chapters.
Reasons for Pluggable Databases
Hardware is becoming more highly specified, and consolidated systems often still have spare capacity. It is more
efficient to enable greater consolidation, thus saving money.
In 11gR2 and previous versions of the database, if one wanted to merge two ebusiness suite databases together
it could be quite awkward due to the clash in identical schema names. Consolidation requirements can be met by
transportable tablespaces, thus enabling the merging of two databases into one, but that does not solve the schema
name clashing. Pluggable databases enable two databases with identical schema names to exist on the same CDB
database server installation.
An alternative to transportable tablespaces or pluggable databases could be to install multiple homes on the
same machine, thus running one DB for each home instead of merging logically.
The advantage that pluggable databases have over this scenario is that 12c pluggable databases share processes
at the OS level, which is more efficient than fully separate databases.
Note that multi-tenancy, which is the name given to using CDB and PDBs, is a paid-for option on top of the DB,
and is likely to need a second release to eliminate any bugs, as with all new options. But that's okay, as it gives us a
chance to learn the new design before we use it in production.
Simple View of 12c Container Structure
The PDBs in Figure
7-1
are self-contained and can be easily plugged or unplugged to a CDB, which further increases
the speed of provisioning during a time of rapid expansion.
