Oracle Database 12c : Multitenant

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. Release timing for
Oracle Database 12c is planned for Calendar Year 2013.

2


Oracle Database 12c
Jean-Philippe Breysse
Oracle Suisse

3


Major Database Focus Areas
SOCIAL

BLOG

101100101001
001001101010
101011100101
010100100101

SMART
METER

BIG
DATA
4


ENGINEERED
SYSTEMS

CLOUD
COMPUTING

Private Database Cloud Architectures
Using Oracle Database 11g
Virtual Machines

Dedicated Databases

share servers

share servers and OS
Increasing Consolidation

5


Schema Consolidation

share servers, OS and database

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

6


Consolidating Databases on Clouds
Key requirements…
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

7


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

8


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

9


Memory and processes required at container level only
System Resources

10


Pluggable vs Separate Databases
Highly Efficient: 6x Less H/W Resource, 5x more Scalable
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

11


Consolidating Databases
Step1: Upgrade databases in-place

Upgrade in Place

12


Consolidating Databases
Step2: Plug-in upgraded databases

13


Managing Shared Resources
Resource management for consolidated databases

Low Priority
Medium Priority

High Priority

14


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
15


Common Users and Privileges
Authorization is checked in the same way as in pre-12.1
 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
 Best practice: Don’t create objects in common user’s schema

16


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

Multitenant Container Database (CDB)

17


Node2

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

Multitenant Container Database (CDB)

18


Node2

Simplified Patching
Apply changes once, all pluggable databases updated

Upgrade
in-place

19


Simplified Upgrades
Flexible choice when patching & upgrading databases

20


Patching via Unplug/Plug
Details
 Plug compatibility
 Xml manifest
 Things to check
– Options
– Character set

– Parameters
– Endianness

 Post-plug, run any necessary SQL patch script in PDB
– Nothing required for binary patches

 This method can be used for upgrades to next patchset

21


Manage Many Databases as One
Backup databases as one; recover at pluggable database Level

One Backup

Point-in-time recovery
at pluggable database level

22


PDB Point-in-time Recovery (PITR)
Recovery isolation at granularity of PDB
 Much simpler/streamlined than tablespace PITR, which is complicated by
difficulties in identifying which metadata to use.
 PDB PITR consists of 3 simple steps from RMAN:

RMAN> restore pluggable database my_db;
RMAN> recover pluggable database my_db until SCN 411010;
RMAN> alter pluggable database my_db open resetlogs;
 All datafiles are recovered in-place, undo is recovered out of place and

applied in-place during open resetlogs.
 Old backups of the PDB will continue to be valid.

23


Manage Many Databases as One
One standby database covers all pluggable databases

24


Fast Provisioning
Pluggable databases can be quickly provisioned from seed
Time Taken to Provision New Database
25
20
15
10
5
0
Non CDB

25


PDB

Clone PDB using
Copy-on-Write File
System

Creating Databases for Test and Development
Fast, flexible copy and snapshot of pluggable databases

26


Multitenant for Provisioning
Fast cloning of PDBs
 PDBs can be cloned from
within the same CDB

27


Cloning a PDB
Example
Local
create pluggable database HCMBI from HCM

28


Multitenant Cloning with Full Copy
Efficient, simple & reliable process
 Orchestration entirely from SQL
– DBA skills only
– No o/s access required

 Parallel Execution Servers
– Fast and efficient

 Clones have unique GUIDs
 Source PDB must be open read only

29


Multitenant Cloning with Snapshot Copy
Thin provisioning of database clones in seconds

create pluggable database DEV44
from CRM_MASTER snapshot copy
 Still SQL with new “as snapshot” clause
 Where not supported receive error

ORA-17517: Database cloning using storage snapshot failed
 Built on copy-on-write capability of underlying file system
 Storage admin’s credentials stored in secure wallet once per CDB
 No subsequent requirement for intervention of storage administrator
30


Snapshot Clone Restrictions
 Local clones only
 Source PDB cannot be dropped
 Source PDB cannot be unplugged
 Both source and cloned PDBs may be opened read-write
 Supported platforms
– Sun ZFS Storage Appliance (ZFSSA)
– Oracle ASM Cluster File System (ACFS)
– NetApp ™

31


Provisioning & Storage Gains with Snapshots
Internal Tests on Sun ZFS Storage Appliance

Full Size (GB) Snap Size (KB)

Relative Size

Full Clone

Snap Clone

% savings

24

0.00058%

9 min, 52 sec

1 min, 52 sec

80%

216

142

0.00007%

1hr, 21 min

2 min, 11 sec

97%

1300

32

140

551

0.00004%

9hr, 7 min

5 min 55 sec

99%


Ideal for consolidating databases on Clouds
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

33


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

34


Q&A

35


36


Oracle Database 12c : Multitenant

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Oracle Database 12c : Multitenant (20)

More from Digicomp Academy Suisse Romande SA (20)

Recently uploaded (20)

Oracle Database 12c : Multitenant