Oracle is doing every thing to jump into
the cloud bandwagon. With 12C, Oracle is trying to address the problem of
Multitenancy through this feature. There is a radical change and a major change
in the core database architecture through the introduction of Container
Databases also called CBD and Pluggable Databases (PDB).
The memory and process is owned by the
Container Database. The container holds the metadata where the PDBs hold the
user data.
You can create upto 253 PDBs including the
seed PDB. In a large setup, it is common to see 20 or 30 different instances
running in production environment. With these many instances, it is a
maintenance nightmare as all these instances have to be separately
•Upgraded
•Patched
•Monitored
•Tuned
•RAC Enabled
•Adjusted
•Backed up
and
•Data Guarded
With Pluggable Databases featureparate
public synonyms. Additionally, 2 PDBs can talk to each other through the
regular DB Link feature.
There is no high startup cost of creating
a database any more. Instead of one instance per day, the shift is into one
instance per many databases. For the developer community, you can be oblivious
of all this and still continue to use the PDBs as if it were a traditional
database, but for the DBAs the world would look like it has changed a lot.
e, you just
have to do all this for ONE single instance. Without this feature, prior to
12C, you would have to create separate schemas and there is always a thread of
security how much ever the isolation we build into it. There are problems with
namespace conflicts, there is always going to be one public synonym that you
can create. With PDBs you can have a separate HR or Scott schema for each PDB,
separate Emp, Dept Tables and s
About
Containers in a CDB
A container
is either a PDB or the root. The root container is a collection of schemas,
schema objects, and nonschema objects to which all PDBs belong.
Every CDB has
the following containers:
Exactly one
root
The root
stores Oracle-supplied metadata and common users. An example of metadata is the
source code for Oracle-supplied PL/SQL packages. A common user is a database
user known in every container. The root container is named CDB$ROOT.
Exactly one
seed PDB
The seed PDB
is a system-supplied template that the CDB can use to create new PDBs. The seed
PDB is named PDB$SEED. You cannot add or modify objects in PDB$SEED.
Zero or more
user-created PDBs
A PDB is a
user-created entity that contains the data and code required for a specific set
of features. For example, a PDB can support a specific application, such as a
human resources or sales application. No PDBs exist at creation of the CDB. You
add PDBs based on your business requirements.
The following
figure shows a CDB with four containers: the root, seed, and two PDBs. Each PDB
has its own dedicated application. A different PDB administrator manages each
PDB. A common user exists across a CDB with a single identity. In this example,
common user SYS can manage the root and every PDB. At the physical level, this
CDB has a database instance and database files, just as a non-CDB does.
Benefits of
the Multitenant Architecture for Database Consolidation
Database
consolidation is the process of consolidating data from multiple databases into
one database on one computer. Starting in Oracle Database 12c, the Oracle
Multitenant option enables you to consolidate data and code without altering
existing schemas or applications.
The
PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a
non-CDB as seen from a client connecting with Oracle Net. The installation
scheme for an application back end that runs against a non-CDB runs the same
against a PDB and produces the same result. Also, the run-time behavior of
client code that connects to the PDB containing the application back end is
identical to the behavior of client code that connected to the non-CDB
containing this back end.
Operations
that act on an entire non-CDB act in the same way on an entire CDB, for
example, when using Oracle Data Guard and database backup and recovery. Thus,
the users, administrators, and developers of a non-CDB have substantially the
same experience after the database has been consolidated.
Cost reduction
By
consolidating hardware and sharing database memory and files, you reduce costs
for hardware, storage, availability, and labor. For example, 100 PDBs on a
single server share one database instance and one set of database files,
thereby requiring less hardware and fewer personnel.
Easier and
more rapid movement of data and code
By design,
you can quickly plug a PDB into a CDB, unplug the PDB from the CDB, and then
plug this PDB into a different CDB. The implementation technique for plugging
and unplugging is similar to the transportable tablespace technique.
Easier
management and monitoring of the physical database
The CDB
administrator can attend to one physical database (one set of files and one set
of database instances) rather than split attention among dozens or hundreds of
non-CDBs. Backup strategies and disaster recovery are simplified.
Separation of
data and code
Although
consolidated into a single physical database, PDBs mimic the behavior of
non-CDBs. For example, if user error loses critical data, a PDB administrator
can use Oracle Flashback or point-in-time recovery to retrieve the lost data
without affecting other PDBs.
Secure
separation of administrative duties
A user
account is common, which means that it can connect to any container on which it
has privileges, or local, which means that it is restricted to a specific PDB.
A CDB administrator can use a common user account to manage the CDB. A PDB
administrator uses a local account to manage an individual PDB. Because a
privilege is contained within the container in which it is granted, a local
user on one PDB does not have privileges on other PDBs within the same CDB.
Ease of
performance tuning
It is easier
to collect performance metrics for a single database than for multiple
databases. It is easier to size one SGA than 100 SGAs.
Support for
Oracle Database Resource Manager
In a
multitenant environment, one concern is contention for system resources among
the PDBs running on the same computer. Another concern is limiting resource
usage for more consistent, predictable performance. To address such resource
contention, usage, and monitoring issues, you can use Oracle Database Resource
Manager (see "Database Resource Manager").
Fewer
database patches and upgrades
It is easier
to apply a patch to one database than to 100 databases, and to upgrade one
database than to upgrade 100 databases.
