PTS DB12c 02 Multitenant v4

1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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.

Oracle Multitenant
Oracle Server Technologies - PTS

Agenda
 Rethinking Architecture for the Database Cloud

 Multitenant Architecture
 Multitenant Capabilities
 Multitenant Manageability
 Upgrading to Multitenant
 Use Cases

Private Database Cloud Architectures
Using Oracle Database 11g
Virtual Machines Dedicated Databases Schema Consolidation
share servers share servers and OS share servers, OS and database
Increasing Consolidation

Private Database Cloud Architectures
Using Oracle Database 12c
Virtual Machines Dedicated Databases Pluggable Databases
share servers share servers and OS share servers, OS and database
Increasing Consolidation

Oracle Database Architecture
Requires memory, processes and database files
System Resources

New Multitenant Architecture
Memory and processes required at multitenant container level only
System Resources

New Multitenant Architecture
Memory and processes required at multitenant container level only
System Resources

Agenda

 Use Cases

Oracle Multitenant
Rethinking Database Architecture
 New database architecture that allows a Container Database (CDB) to

hold zero, one, or many Pluggable Databases (PDBs)
 Oracle Database 12c Release 1 supports both the new multitenant
architecture and the old “non-CDB” architecture
 PDB is fully compatible with a non-CDB

Rethinking Database Architecture
Before 12.1 - Common Data Dictionary
 Oracle Data Dictionary contains both Oracle Metadata and Application

Metadata
 Both are held in the same dictionary tables
 This “intermingling” of metadata makes upgrading an application, and
moving it around, complicated

Common Data Dictionary
Before 12.1: intermingled over time
ta ta ta
r Da y Da Da
se
r r ar
y r ry
U na se n se na
io U io U io
D ic t ic t ic t
D D
ta ta ta
Da Da Da
ta ta ta
Da Da Da
ta ta ta
Me Me Me
Database Created Tables, Code, Data added Mature Database

Oracle Data and User Data
 Pluggable Databases
fixes this with
in-database
virtualization
OBJ$ TAB$ SOURCE$ EMP DEPT

 Only
The data dictionaryofis
the definition
intermingled
the with the
Oracle system
… … customer’s metadata
remains

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

CDB Architecture
So essentially,
The part with just the

“customer stuff” is the
PDB PDB (Pluggable
Database).
The part with just the

Root “Oracle stuff” is called
the Root.

Multitenant Architecture
Components of a Multitenant Container Database (CDB)
PDBs
Root
Pluggable Databases (PDBs)
CDB

Multitenant Architecture
 Multitenant architecture can currently

support up to 252 PDBs
Database  A PDB feels and operates identically to a
Link
non-CDB
 You cannot tell, from the viewpoint of a
connected client, if you’re using a PDB or
a non-CDB

CDB Architecture
 PDBs share common SGA and
background processes
 System administrators can connect to
CDB root container to administer single
system image
 Client foreground sessions see only the
single PDB they connect to
and see it just like a non-CDB

CDB Architecture – Scalability
 Add PDBs to a CDB whose memory is
pre-sized to take full advantage of what
the machine offers
 Normal SGA block management is
graceful as PDBs compete for memory
 Compare this with adding the non-CDB
that then prevents all non-CDBs fitting
into memory – you fall over the paging
“cliff”

Pluggable Databases vs Separate Databases
Highly Efficient: 6x Less H/W Resource, 5x more Scalable
20 Separate
OLTP benchmark comparison Pluggable
Only 3GB of memory vs. 20GB 15
Memory Utilized
memory used for 50 databases
Pluggable databases scaled to 10

over 250 while separate
database instances maxed at 50
0
1 10 20 50 80 110 140 170 200 230 250
# Databases

Files in the CDB
Namespaces
 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

Creating CDBs with DDL
Example (with Oracle Managed Files)
create database newcdb

user sys identified by sys_password
user system identified by system_password
extent management local
default tablespace users
default temporary tablespace temp
undo tablespace undotbs1
enable pluggable database
seed
system datafiles size 125m autoextend on next 10m maxsize unlimited
sysaux datafiles size 100m;

Creating CDBs with DBCA

Provisioning a PDB with DDL
Example (with Oracle Managed Files)
create pluggable database CRM
admin user crmadm identified by CRMpass123
roles = (DBA);
Example (without Oracle Managed Files)

create pluggable database CRM
admin user crmadm identified by CRMpass123
roles = (DBA)
file_name_convert = ('/disk1/oracle/dbs/pdbseed/',
'/disk1/oracle/dbs/salespdb/');

Provisioning a PDB with EM Cloud Control 12c
Example

Fast Cloning of PDBs
 PDBs can be cloned from PDBs within
the same or remote database
 PDB carries lineage from the PDB it
was cloned from
 Full clone parallelized at the
granularity of the database block
 Within-CDB cloning can be done
using “SNAPSHOT COPY” option
when supported by underlying
filesystem
– ZFS, ACFS, NetApp

Cloning a PDB with DDL
Examples
Local
create pluggable database HCMBI from HCM
Remote (DB Link)

create pluggable database HCMBI from HCM@us.acme.db1
Snapshot Copy
create pluggable database HCMBI from HCM snapshot copy

PDB Cloning with EM Cloud Control 12c
Example

PDB Cloning with SQL Developer
Example

Fast Provisioning of PDBs
Pluggable databases can be quickly provisioned
Time Taken to Provision New Database

25
20
15
10
0
Non CDB PDB Clone PDB using
Copy-on-Write File
System

Unplug / plug
Simply unplug from the old CDB…
 In its unplugged state, a PDB is a self-

contained set of data files and an XML
metadata file

Unplug / plug
…and plug in to the new CDB…
 Moving between CDBs is a simple case

of moving a PDB’s metadata
 An unplugged PDB carries with it lineage,
opatch, encryption key info etc

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

Users: Local vs Common
 Local User
– the successors for customer-created
users in a non-CDB
– defined only in a PDB
– can administer a PDB
 Common User
– defined in the root and is represented
in every PDB
– 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
Authorization is checked in the same way as as pre-12.1
create user c##Über_Administrator

identified by pwd container=all
 A common user can be granted privileges locally in a PDB 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
 Authorization is checked in the container where SQL is attempted
considering only the privileges of the user in that container

Services and Sessions
Connections are established the same as pre-12.1
 Session are created essentially the same as before

 Specify Listener location, port, username / password, servicename
 Service definitions now have new PDB property
 You can connect to a PDB only by using network authentication
 Local users can create sessions only in the PDB where they are
defined with Create Session privilege
 A common user can create a session in any PDB where it has
Create Session

RAC and Services in PDBs
Improved services with the control of RAC and flexibility of PDBs
 Each instance in a RAC Cluster opens

the CDB as a whole.
 PDBs opened automatically where
services are defined
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

Agenda

 Use Cases

Manage Many as One with Multitenant
Backup databases as one; recover at pluggable database level
One Backup
Point-in-time recovery
At pluggable database level

Manage Many as One with Multitenant
One standby database covers all pluggable databases

Multitenant for Simplified Patching
Apply changes once, all pluggable databases updated
Upgrade
in-place

Multitenant for Upgrades
Flexible choice when patching & upgrading databases

Improved Agility With Changing Workloads
Expand Cluster to Support Flexible Consolidation Model
Services
CDB Instance 1 CDB Instance 2

Single SGA per
CDB Instance
Node1 Node2
Multitenant Container Database (CDB)

Improved Agility With Changing Workloads
Expand Cluster to Support Flexible Consolidation Model
Services
CDB Instance 1 CDB Instance 3 CDB Instance 2

Single SGA per
CDB Instance
Node1 Node3 Node2
Multitenant Container Database (CDB)

Agenda

 Capabilities Enabled
 Use Cases

Managing Multitenant Databases
Manage many as one
Schemas
Container Database
Pluggable DBs Users, Roles &

CRM ERP
Seed HR
Services
DB
Data Dictionary
Managed Globally
PDBAs
by CDBA and
Locally by PDBAs Tablespaces

Management of Pluggable Databases
Separation of Duties—CDBA vs. PDBA
Administration
Performance Backup &
& Tuning Recovery
Storage Users & SQL and Resource

Migration System
Management Roles Session Management
CDB Only CDB Management: PDB Management:

CDB and PDB Holistic database and instance Application centric management
management

Managing Resources between PDBs
 Use Resource Manager to control shared resources among PDBs
– CPU
– Exadata I/O
– Sessions
– Parallel execution servers
 Resource Manager policy controls how resources are utilized

– Default configuration that works, even as PDBs are added or removed
– Hard limits, for “get what you pay for”

PDB Resources Policies
 Based on two notions:

– A number of resource shares is allocated to each PDB
– A “cap” (a.k.a. maximum utilization limit) may be applied to each PDB
 CPU Scheduling of PDBs
– Fine-grained scheduling of sessions performed every 100ms
– Resource Manager maintains an internal queue
– Plans applied dynamically

Manage CPU
A CDB Resource Plan uses
shares to specify how CPU
is distributed between PDBs
2 Shares 1 Share 1 Share
Pluggable Database Shares Guaranteed CPU Maximum CPU
HCM 2 2/4 = 50% 100%
CRM 1 1/4 = 25% 100%
ERP 1 1/4 = 25% 100%

Manage CPU
A CDB Resource Plan uses
utilization limits to limit the
CPU usage for a PDB.
Note: With utilization limits,
your CPU may be under- 2 Shares 1 Share 1 Share
utilized. 50% 50%
Pluggable Database Shares Guaranteed CPU Utilization Limit Maximum CPU
HCM 2 2/4 = 50% 100%
CRM 1 1/4 = 25% 50% 50%
ERP 1 1/4 = 25% 50% 50%

Manage CPU
Configure a default directive:
the default shares and utilization
limit for PDBs.
2 Shares Default Default
(Default directive) 1 50%
HCM 2 2/4 = 50% 100%
CRM default (1) 1/4 = 25% default (50%) 50%
ERP default (1) 1/4 = 25% default (50%) 50%

Manage CPU
With a default directive, you
don’t need to modify the
resource plan for each PDB
plug and unplug
2 Shares Default Default Default
(Default directive) 1 50%
HCM 2 2/5 = 40% 100%
CRM default (1) 1/5 = 20% default (50%) 50%
ERP default (1) 1/5 = 20% default (50%) 50%
DEV default (1) 1/5 = 20% default (50%) 50%

Parallel Statement Queuing in PDBs
Specifies the probability Limit the total number Limit the Auto-DOP of
that this PDB will get to of parallel servers the the PDB’s parallel
launch the next parallel PDB can use at a operations.
operation time.
PDB Shares Parallel Server Percentage Parallel Degree Limit
ETL 2 50 4
BI 1 50 8
DW 1 50 16

Enterprise Manager Cloud Control 12c
Discovered Database 12c Targets

CDB Home Page

PDB Home Page

CDB Performance Home Page

ASH Analytics Page showing CDB and PDBs

SQL Monitoring Page showing CDB and PDBs

Administering Database Users for CDB and PDBs

Creating a Common User if CDB is Selected

Agenda

 Use Cases

Upgrading Non-CDB to a Pluggable DB
Two Methods
01001011001001001001011
Plug as PDB
10010010101001001010101
0011010100101010010 Method
CDB
Standalone Non-CDBs of version DB 12.1 or
later. An XML description is used
to create the PDB.
Non-CDBs of version 11.2.0.3.

CDBA or later. Datafiles will be copied
over as part of the migration. PDBs
Use Datapump or Goldengate
Data Pump
01001011001001001001011 /
10010010101001001010101
0011010100101010010 Replicate
Method
Standalone

Upgrade to PDB from Oracle Database 11g
Plug Non-CDB into CDB
① 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 (part 1)
begin
DBMS_PDB.Describe(
PDB_Descr_File => '/oracle/home/hcmmeta.xml');
end;

Plug Non-CDB into CDB
Example (part 2)
create pluggable database exnoncdb

as clone
using ‘/oracle/home/hcmmeta.xml’
nocopy
tempfile reuse;
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
alter pluggable database exnoncdb open;

PDB Provisioning: Migrate non-CDB to PDB

Migrate using Replication
① Provision new PDB from Seed

② Replicate using technologies such as
Oracle GoldenGate or Data Pump
New in 12.1: Full Transportable

Database Export/Import makes
maximum use of transportable
tablespaces in the single expdb and
impdb commands.
(Backported to 11.2.0.3.)

Agenda

 Use Cases

Multitenant Database for Test and Development
Fast, flexible copy and snapshot of pluggable databases

Consolidation of Disparate Applications
Shared overhead of memory and processes
System Resources

Multitenant Database. Perfect for SaaS.
Multi-tenancy implemented by the Database, not the Application

Exploiting the Flexibility of CDBs
 Servers can host multiple CDBs

Gold SLA
Sliver SLA  CDBs could be at different patch levels or
Bronze SLA
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

Self-Service Database as a Service (DBaaS)
Pick from standard sizes and service levels
GOLD RAC, Data Guard, Daily Incrementals
SILVER Data Guard, Daily Incrementals
BRONZE Weekly Full Backups

Multitenant Database. Perfect for ISVs.
Packaged apps and reference data are easily distributed

Summary
Oracle Multitenant Database
What customers are saying…
“Oracle Multitenant is a step forward in that it gives us more control over our schemas and
applications; to be able to isolate them, give definitive statements on how performance is working
and be able to manage more databases better.” Carfax
“With Oracle Database 12c, we can now copy an entire database from one instance to
another using full transportable export/import. This minimizes the downtime when migrating
clients’ databases.” Accenture
“Oracle Multitenant allows us to consolidate hundreds of databases onto a RAC environment

that guarantees the separation that drove us to put them on separate servers previously.”
Logical Power
“Undoubtedly the number one most compelling feature of Oracle Database 12c is the support for
consolidation. Oracle Multitenant can share memory resources, and make management easier
because it is still a single database instance.” Pythian

Oracle Multitenant
Summary
No application changes
Isolation and multitenancy
Fast provisioning and cloning
Secure and highly available
Lower IT costs
Manage many as one
Greater resource utilization
Performant and scalable


PTS DB12c 02 Multitenant v4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PTS DB12c 02 Multitenant v4

Uploaded by

Copyright:

Available Formats

1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

The following is intended to outline our general product

2 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Oracle Server Technologies - PTS

 Rethinking Architecture for the Database Cloud

4 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

share servers share servers and OS share servers, OS and database

5 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

share servers share servers and OS share servers, OS and database

6 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

8 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

9 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Rethinking Architecture for the Database Cloud

10 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 New database architecture that allows a Container Database (CDB) to

11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Oracle Data Dictionary contains both Oracle Metadata and Application

12 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Database Created Tables, Code, Data added Mature Database

13 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

OBJ$ TAB$ SOURCE$ EMP DEPT

14 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

15 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

The part with just the

The part with just the

16 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

17 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Multitenant architecture can currently

18 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

20 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Only 3GB of memory vs. 20GB 15

Pluggable databases scaled to 10

21 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Each PDB has its own set of tablespaces

22 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

create database newcdb

23 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

24 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Example (without Oracle Managed Files)

25 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

26 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

27 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Remote (DB Link)

28 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

29 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

30 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Time Taken to Provision New Database

31 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 In its unplugged state, a PDB is a self-

32 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Moving between CDBs is a simple case

33 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

34 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

35 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

create user c##Über_Administrator

 A common user can be granted privileges locally in a PDB and

36 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Session are created essentially the same as before

37 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Each instance in a RAC Cluster opens

ERP PDB is open on node 4 only