The document discusses Oracle 12c's multitenant architecture which introduces the concepts of a container database (CDB) and pluggable databases (PDBs). A CDB can host multiple PDBs that appear as independent databases but share resources. PDBs can be unplugged from one CDB and plugged into another, allowing for quick provisioning and cloning of databases. The multitenant architecture provides benefits like consolidation of databases, rapid provisioning and cloning using SQL, and easier patching and upgrades.

1. Oracle 12c Multitenant
Architecture
Introduction of CDB and PDB
Databases
(Reference – Oracle documentation)
1

2. What is Multitenant
• Multi-tenancy is an design in which a single
instance of a software application serves multiple
customers. Each client is called a tenant.
• With a multitenant architecture, a software
application is designed to provide all tenant a
committed share of the instance including its
data, configuration, user management, tenant
individual functionality and non-functional
possessions.
Check detailed contents on
http://dbaboss.com/
2

3. • It has been an organizational outlandish when multiple
databases are running in one machine. The backups need to
be run independently. Each database has memory footmark
and each database has background processes. This increases
the capacity of the server on what it can lever in terms of the
loads. By joining into one container database and at the same
time keeping all of them as separate databases are a great
thing from association, 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.
Check detailed contents on
http://dbaboss.com/
3

4. Oracle 12c Multitenant Architecture
Overview
• A new selection for Oracle Database 12c,
Oracle Multitenant supplies a new
architecture that allows a multitenant
container database to hold many pluggable
databases. At present database can simply be
accepted with no application changes
required. Oracle Multitenant fully
complements other options, including Oracle
Real Application Clusters and Oracle Active
Data Guard.
Check detailed contents on
http://dbaboss.com/
4

5. • The multitenant architecture empowers an
Oracle database to function as a multitenant
container database (CDB) that includes zero,
one, or many customer-created pluggable
databases (PDBs).
• A PDB is a transportable collection of
schemas, schema objects, and nonschema
objects that appears to an Oracle Net client as
a non-CDB. All Oracle databases before Oracle
Database 12c were non-CDBs.
Check detailed contents on
http://dbaboss.com/
5

6. What is CDB, PDB and Seed Database
• Container Database (CDB):
The primary database that comprises numerous plugged-in databases.
Numerous operations can be performed at the container level to reduce
management costs. A database is generated as either a CDB or a non-CDB.
On the apparent this seems very similar to a conventional Oracle database, as
it contains most of the working parts you will be already familiar with (control
files, data files, undo, tempfiles, redo logs etc.). It also lines the data
dictionary for those objects that are owned by the root container and those
that are visible to all PDBs.
A container is a pool of schemas, objects, and related structures in a
multitenant container database (CDB) that appears logically to an application
as a separate database. Within a CDB, each container has a unique ID and
name.
It also called root container.
Check detailed contents on
http://dbaboss.com/
6

7. • Pluggable Database (PDB):
A set of schemas, objects, and non-schema objects that can be
plugged and unplugged from a container database. The PDB
appears to Oracle Net and end users as a Non cdb database in
and of itself but is actually managed within a container that may
have many PDBs. Since the CDB comprises most of the working
parts for the database, the PDB only needs to contain
information precise to itself. It does not need to worry about
controlfiles, redo logs and undo etc. As an alternative it is just
made up of datafiles and tempfiles to handle it's own objects.
This contains it's own data dictionary, containing information
about only those objects that are specific to the PDBSeed
Database.
PDBs isolate data and operations so that from the standpoint of
a user or application, each PDB appears as if it were a traditional
non-CDB.
Check detailed contents on
http://dbaboss.com/
7

8. • The maximum limit to the total number of Pluggable databases
within a container database is close to 250. So you can have up to
250 pluggable databases or PDBs within one container database or
CDB. It is clear that there is one-to-many relationship between CDB
and PDBS.
• (Seed PDB):
A default PDB that the system uses as a template to quickly
facilitate other user-created PDBs. Within, it’s called PDB$SEED
• Below picture refer in Oracle docs
Check detailed contents on
http://dbaboss.com/
8

9. Check detailed contents on
http://dbaboss.com/
9

10. Check detailed contents on
http://dbaboss.com/
10

11. Check detailed contents on
http://dbaboss.com/
11

12. • The new multitenancy choice in Oracle Database 12c that permits you to
create several virtual databases (PDB) called pluggable databases or containers
in a single physical database called container database (CDB). The CDB is the
one that has the Oracle instance connected with it, i.e. it has the background
processes such as pmon, smon and the memory areas such as buffer cache
and large pool. The PDBs do not have their own instance; but take up house
inside the CDB, with some extra storage private to them. This preparation
permits you to address the PDBs as independent databases. So you can create
a user called, say, DBABOSS in every PDB, as an alternative of creating a new
database for creating these users. This is highly useful in case of applications
that require a specifically named schema, e.g. PeopleSoft have need of a user
so-called SYSADM. If you want to place numerous PeopleSoft applications
inside one database, you can't, since you can't create more than one user with
the name SYSADM. So you had to resort to producing several databases to
hold several copies of the application. Each of these databases had its own
memory and resource overheads. In a multitenancy model you can create
several PDBs instead of actual databases. Each PDB can then have a user
named SYSADM and run its copy of the PeopleSoft application but without
consuming any extra memory and CPU.
Check detailed contents on
http://dbaboss.com/
12

13. • While these PDBs are accommodated in a single CDB, they have the many of the
individualities of a regular independent database. For instance you can set a
specific optimizer limitation to different values in different PDBs. You can, of
course, start and shutdown a PDB leaving other PDBs in the CDB unaffected. You
can back up PDBs independently, as RMAN knows which specific files are relevant
for the PDBs. You can restore individual PDBs, even perform a point in time
recovery for a PDB while the others are running.
• This allows you to create a accurate "cloud database" where you can host as
numerous databases as you want without increasing the memory and CPU
footmark. This is principally useful when you have financial limitations that prevent
creation of supplementary databases forcing difficulties in development cycles.
You can spin up a PDB very quickly to host the development effort, or even clone it
from another PDB from either the same CDB or a different one, even a different
server. This ability of creating virtual databases unfastens the database
provisioning from hardware provisioning. All the PDBs share the same resources. If
the overall request becomes too high, all you have to do add the resources to the
CDB and all the PDBs get the benefit immediately. Perhaps the biggest advantage
is seen during upgrades. Instead of upgrading multiple databases, all you have to
do is to upgrade the CDB and all PDBs in it are directly upgraded
Check detailed contents on
http://dbaboss.com/
13

14. Benefits
• Achieve many databases as one.
• Come across service-level prospects with
built-in workload resource management.
• Keep the isolation of separate databases
without shifting applications or access rights.
• Increase scalability and server consumption.
• Oracle multitenant databases were developed
to help companies take advantage of
virtualization.
Check detailed contents on
http://dbaboss.com/
14

15. • High association compactness.
The many pluggable databases in a single container database share its
memory and background processes, permitting you operate many
more pluggable databases on a precise platform than you can single
databases that use the old architecture. This is the equal profit that
schema-based association brings. But there are noteworthy barriers to
adopting schema-based consolidation, and it causes ongoing operating
problems. The new architecture removes these adoption barriers and
operating problems.
Check detailed contents on
http://dbaboss.com/
15

16. • Speedy provisioning and cloning using SQL.
. A pluggable database can be unplugged from one container database
and plugged into another. Instead, you can clone one, within the same
container database, or from one container database to another. These
operations, together with creating a pluggable database, are done with
new SQL commands and take just seconds. When the fundamental file
system supports thin provisioning, many terabytes can be cloned
almost instantaneously simply by using the keyword snapshot in the
SQL command
Check detailed contents on
http://dbaboss.com/
16

17. • New standards for rapid patching and upgrades.
The deal of time and effort to patch one container database results in
patching all of its many pluggable databases. To patch a single
pluggable database, you simply unplug/plug to a container database at
a different Oracle Database software version.
• Accomplish many databases as one.
By combining existing databases as pluggable databases,
administrators can manage many databases as one. For example, tasks
like backup and disaster recovery are performed at the container
database level.
• Vibrant between-pluggable database resource management.
Oracle Database 12c Resource Manager is extended with specific
functionality to instantly control the competition between the
pluggable databases within a container database
Check detailed contents on
http://dbaboss.com/
17

18. What is extra
• Unplug and Plug PDB
What is additional? We can plug out (unplug) a database from
one container database and then plug in into another container
database. This is attractive 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
Check detailed contents on
http://dbaboss.com/
18