Simplify Consolidation with Oracle Pluggable Databases

The following is intended to outline our general product
direction. It is intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracle's products
remains at the sole discretion of Oracle.

Simplify Consolidation
with
Oracle Pluggable Databases
Bryn Llewellyn
Distinguished Product Manager
Oracle Headquarters

Agenda
 Customer challenges
 Oracle Pluggable Databases meets these challenges
 Pluggable Databases architecture
 Upgrading/migrating to Pluggable Databases
 Pluggable Databases and Resource Manager

Customer Challenges
 Consolidating:
– customers are under huge pressure to cut CapEx and OpEx by
consolidating many databases onto few platforms
 Provisioning:
– they spend a huge amount of time creating databases, creating up-to-date
clones for dev/test, and moving them from place to place
 Patching:
– they also spend time (not quite so frequently) attending to the version of
the Oracle Database software: applying CPUs and PSUs and upgrading

Oracle Database 12c Meets these Challenges
 A CDB contains zero, one, or many PDBs
 A PDB is backwards compatible with a non-CDB
 Each instance in a RAC opens the CDB as a whole.
 A foreground session sees only the single PDB it connects to
and sees it just like a non-CDB
 The system administrator connects to the root of the CDB
and sees a single system image
 Resource Manager is extended with new between-PDB capabilities
Pluggable Databases

Agenda
 Customer challenges – the root cause
 Pluggable Databases meets these challenges

Common Data Dictionary
Before 12.1: pollution over time
Database Created
Data
Dictionary
User Data
Meta
Data
Mature Database
Data
Dictionary
User Data
Meta
Data
Tables, Code, Data added
Data
Dictionary
User Data
Meta
Data

Agenda

OBJ$ TAB$ SOURCE$
…
Oracle Data and User Data
OBJ$ TAB$ SOURCE$
…
EMP DEPT
…
 The data dictionary is
polluted by the
customer’s metadata
OBJ$ TAB$ SOURCE$
…
 Pluggable Databases
fixes this with
in-database
virtualization
 Only the definition of
the Oracle system
remains

Horizontally Partitioned Data Dictionary
OBJ$ TAB$ SOURCE$
…
EMP DEPT
…
OBJ$ TAB$ SOURCE$
…
 Oracle-supplied
objects such as
views, PL/SQL, etc.,
are shared across
all PDBs using
object “stubs”

Root
PDB
CDB Architecture

Agenda

Unplug / plug
 A PDB feels and operates identically to a
non-CDB
 You cannot tell, from the viewpoint of a
connected client, if you’re using a PDB or
a non-CDB
Simply unplug from the old CDB…

Unplug / plug
…and plug in to the new CDB…
 Moving between CDBs is a simple case
of moving a PDB’s metadata
 Upgrades and patching becomes much
simpler
 An unplugged PDB carries with it lineage,
opatch, encryption key info etc

Unplug / plug
Example
alter pluggable database HCM
unplug into '/u01/app/oracle/oradata/…/hcm.xml'
create pluggable database My_PDB
using '/u01/app/oracle/oradata/…/my_pdb.xml'
Plug
Unplug

CDB Architecture
If you can have one PDB…
 The CDB architecture can currently
support up to 252 PDBs
Database Link

Fast Cloning of PDBs
 PDBs can cloned from PDBs within the
same database
 PDBs can be cloned from remote PDBs
 PDB carries lineage from the PDB it was
cloned from

Cloning a PDB
Example
create pluggable database HCMBI from HCM
create pluggable database HCMBI from HCM@us.acme.db1
Remote (DB Link)
Local

PDB Cloning
 Full clone doesn’t need to source PDB to be quiesced
(same approach as for RMAN online backup)
parallelized at the granularity of the database block
 When the underlying filesystem supports this,
within-CDB cloning can be done using “snapshot copy”
specified in the SQL statement

Rapid Provisioning of PDBs
 PDB’s can be rapidly provisioned
from the seed
0
5
10
15
20
25
Non PDB PDB PDB and Change on
Copy File system
Time Taken to Provision New Database

Provisioning a PDB
create pluggable database CRM
admin user crmadm identified by CRMpass123
roles = (DBA)
Example

Files in the CDB
 Each PDB has its own set of tablespaces
including SYSTEM and SYSAUX
 PDBs share UNDO, REDO
and control files, (s)pfile
 By default the CDB has a single TEMP
tablespace but PDBs may create their
own
Namespaces

CDB Architecture – Dynamics
 PDBs share common SGA and
background processes
 Foreground sessions see only the PDB
they connect to

CDB Architecture – Scalability
0
0.5
1
1.5
2
2.5
3
CRM HCM ERP BI WEB
GB
Pluggable Database
MEMORY
 Only small increments in memory as
additional PDB’s are added

OLTP benchmark comparison
Only 3GB of memory vs. 20GB
memory used for 50 databases
Pluggable databases scaled to
over 250 while separate
database instances maxed at 50
Pluggable Databases vs Separate Databases
Highly Efficient: 6x Less H/W Resource, 5x more Scalable
0
5
10
15
20
1 10 20 50 80 110 140 170 200 230 250
Separate
Pluggable
# Databases
MemoryUtilized

Users  Local users are the successors for
customer-created users in a non-CDB
 A local user is defined only in a PDB
 A local user can administer a PDB
 A common user is defined in the root
and is represented in every PDB
 A common user can log into any PDB
where it has “Create Session” and can
therefore administer a PDB
 The Oracle system is owned by common
users

Common Users and Privileges
 A common user can be granted privileges locally in a PDB (or root)
and therefore differently in each container
 A common user can, alternatively, be granted a system privilege
commonly – the grant is made in root and every PDB, present and
future
 You can create a common role
 A common role can be granted to a common user commonly
 Authorization is checked in the container where the SQL is attempted
considering only the privileges that the user has in that container
Authorization is checked in the same way as as pre-12.1

Creating Common Users
Example
create user c##Über_Administrator
identified by pwd container=all

Services and Sessions
 Listener location, listener port, service name, username, password
 Now a service has a new property: the initial PDB
 A session is created in essentially the same as before
 You can connect to a PDB only by using network authentication
 A local user can create a session only in the PDB where it is
defined, subject, to having Create Session there
 A common user can create a session in any PDB where it has
Create Session
The “five facts” have the same result as pre-12.1

RAC and Services in PDBs
Improved services with the control of RAC and flexibility of PDBs
ERP PDB is open on node 4 only
HCM PDB is open on node 1 & 2 only
CRM PDB is open on all the nodes

Exploiting the Flexibility of CDBs
 Servers can host multiple CDBs
 CDBs could be at different patch levels or
require different SLAs e.g.
– Gold CDB requires RAC & Data Guard
– Silver CDB requires only Data Guard
– Bronze requires only backups
 PDBs can trivially move from one CDB to
another to take advantage of SLAs and
patches
Gold SLA
Sliver SLA
Bronze SLA

Dictionary and Performance views
 The performance views have a new Con_ID column
 There’s a new CDB_ dictionary view family with a Con_ID column
 These are so-called container-data objects
 When queried from a PDB, the results show only Con_ID for that PDB
 When queried from the root, the results may show all Con_ID values
 The containers you see depend on an attribute of the user that lists
these (or says “all – present and future”)
PDB-to-PDB privacy; overall system image

Per PDB vs per CDB
Have your cake and eat it
Single Oracle Software Version
Data Guard
Scheduled RMAN Backups
Some parameters/properties
e.g. homogeneous character set
Redo and Undo
RMAN point-in-time recovery
Ad hoc RMAN backups
Flush shared pool
Parameters where
IsPDB_Modifiable = 'TRUE'
Per CDB Per PDB

Agenda

Upgrade to PDB from Oracle Database 11g
Upgrade 11g database and plug in
① Upgrade 11.2 database to 12.1 in place
② Place the non CDB into read only mode
③ Connect to non CDB and generate a
description file (manifest)
④ Shutdown the non CDB
⑤ Plug in non CDB to CDB
⑥ Post-plug script to remove redundant
metadata for the Oracle system

Generate the PDB Manifest
Example
begin
DBMS_PDB.Describe(
PDB_Descr_File => '/oracle/home/hcmmeta.xml');
end;

Migrate using Replication
① Provision new PDB from Seed
② Replicate using technologies such as
Oracle GoldenGate or Data Pump

Over the Wire Migration via Data Pump
Full Transportable Tablespace – new in 12.1, backported to 11.2.0.3
impdp system/manager123@cdbdatabase/hcm
FULL=y
NETWORK_LINK=com.us.acme.db1
DIRECTORY=dmpdir

Agenda

Managing Resources between PDBs
 PDBs vie for shared resources
 Using Resource Manager, you can control
– CPU
– Exadata I/O
– Sessions
– Parallel execution servers
 Configure a policy that controls how resources are utilized
– Default configuration that works, even as PDBs are added or removed
– Hard limits, for “get what you pay for”

Managing Resources between PDBs
 The model is “industry standard” based on two notions:
– A number of shares is allocated to each PDB
– A “cap” (a.k.a. maximum utilization limit)
may be applied to each PDB
 NOTE: the PDB identifier is embedded into every major structure

Summary

Oracle Database 12c Meets the Challenges
 In-database virtualization
 Implemented by horizontally partitioning the data dictionary tables
 Pluggability
 Next generation consolidation
 It’s a pure deployment choice: neither the database backend,
nor the client code, needs to be changed
Pluggable Databases

Simplify Consolidation with Oracle Pluggable Databases

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Simplify Consolidation with Oracle Pluggable Databases

Similar to Simplify Consolidation with Oracle Pluggable Databases (20)

Recently uploaded

Recently uploaded (20)

Simplify Consolidation with Oracle Pluggable Databases