Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Oracle Multitenant
A new architecture for consolidating databases and simplifying operations in the cloud
Arush Jain
Senior Consultant

Agenda
Rethinking Architecture for the Database Cloud
Multitenant Architecture
Capabilities Enabled
Managing Multitenant Environment
Upgrading to Multitenant
Use Cases & Customer Successes
1
2
3
4
5
Oracle Confidential – Internal/Restricted/Highly Restricted 3
6

Agenda
1
2
3
4
5
4
6

Database Consolidation on Clouds
Traditional consolidation methods
Schema Consolidation
ConsolidationDensity
5
Shared Servers Shared Servers & OS Shared Servers, OS, & Database
Virtual Machines Clustered Databases

Oracle Multitenant
Simplifies consolidation; enables Database as a Service
Multitenant Database
6
Schema Consolidation
ConsolidationDensity
Shared Servers & OS Shared Servers, OS, & Database
Virtual Machines Clustered Databases
Shared Servers

Agenda
1
2
3
4
5
7
6

Oracle Database Architecture
Requires memory, processes and database files
8
System Resources
GL OE AP

APOEGL
New Multitenant Architecture
Memory and processes required at container level only
9
System Resources
GL OE AP

GL OE AP
Oracle Database Architecture
More efficient utilization of system resources
10
System Resources

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

• Multitenant architecture can currently
support up to 252 PDBs
• PDB / non-CDB compatibility guarantee:
You cannot tell, from the viewpoint of
a connected client, if you’re using a
PDB or a non-CDB
DB Link
GL OE AP

A Pluggable Database Is a Portable Database
13
Unplugging a PDB and plugging it in
GL OE AP
PO AP
• Simply unplug from the old
CDB…
• …and plug it into 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 – Orchestration Performed Using SQL
You already know how to use it!
alter pluggable database OE
unplug into '/u01/app/oracle/oradata/…/oe.xml'
create pluggable database My_PDB
using '/u01/app/oracle/oradata/…/oe.xml'
Plug
Unplug

Multitenant Scalability
Only small increments in memory as additional PDBs are added
0
0.5
1
1.5
2
2.5
3
GL OE AP
GB
Pluggable Database
MEMORY
0
0.5
1
1.5
2
2.5
3
GL OE AP PO
GB
Pluggable Database
MEMORY
0
0.5
1
1.5
2
2.5
3
GL OE AP PO AR
GB
Pluggable Database
MEMORY
GL OE AP PO HR

Multitenant vs Separate Databases
• OLTP benchmark
comparison
• Only 3GB of memory
vs. 20GB memory used
for 50 databases
• Multitenant
architecture scaled to
over 250 db’s while
separate database
instances maxed at 50
Highly Efficient: 6x Less H/w resource, 5x more scalable

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

Utilize Spare Capacity
• Standalone systems seldom perfectly sized for workload
• They must be “configured for high water”
– Basic requirement is to be big enough
– Efficient use of resources secondary consideration
Consolidate to make more efficient use of capacity
Unconsolidated Consolidated
• Consolidated Server
– Comparable aggregate capacity
– Greater productive resource utilization
– Higher consolidation density

Agenda
1
2
3
4
5
19
6

Manage Many Databases as One
Backup databases as one; recover at pluggable database Level
20
GL OE AP
Point-in-time recovery at pluggable database level
One Backup

Manage Many Databases as One with Multitenant
One standby database covers all pluggable databases
21
Production Container Database
GL OE AP GL OE
Standby Container Database
AP

Simplified Patching and Upgrades
Apply changes once, all pluggable databases updated
22
GL OE AP
In-place
12.1 12.1 12.112.X 12.X 12.X

Simplified Patching and Upgrades
Flexible choice when patching & upgrading databases
23
Original Container Database 12.1
GL OE AP GL OE
Upgraded Container Database 12.x

SILVER
BRONZE
GOLD
Unprecedented Agility with Portable Pluggability
PDB migrates through SLAs as it becomes more mission critical
24
RAC, Data Guard
RAC
Backups

• Consolidation with Multitenant frees up
– Memory
– CPU Cycles
• Oracle Database In-Memory wants
– Memory
– CPU Cycles
25
Database In-Memory Works (Better) with Multitenant
GL OE
AP
Multitenant consolidation “gives back” resources that DB In-Memory needs
Column Format
Order Fact
DB In-Memory

Agenda
1
2
3
4
5
26
6

Managing Shared Resources
Resource management in a multitenant environment
27
GL OE AP
High Priority Medium Priority Low Priority

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

Agenda
1
2
3
4
5
6

GL
12.1
AP
12.1
OE
12.1
Step 1. Upgrade databases in place
In-place
GL
10.2
AP
11.1
OE
11.2

GL
12.1
AP
12.1
OE
12.1
Step 2. Plug in upgraded databases
GL
12.1
AP
12.1
OE
12.1 12.1
GL
12.1
AP
12.1
OE

Step 3. Change applications to work with MultitenantStep 3. Change applications to work with Multitenant
• No application changes required!
GL
12.1
AP
12.1
OE
12.1

Migrate Using Replication
① Provision new PDBs from Seed
② Replicate using technologies such as Oracle
GoldenGate or Data Pump
New in 12.1, you ask that full database export
and full database import make maximum use
of transportable tablespaces in the single
expdb and impdb commands.
(Backported to 11.2.0.3.)
Seed
GL OE
OEGL

Expand cluster to support flexible consolidation model
Improved Agility With Changing Workloads
Services
Single SGA per
CDB Instance
Node 1
CDB Instance 1
Node 2
CDB Instance 2

Node 1
Expand cluster to support flexible consolidation model
Improved Agility With Changing Workloads
Node 3
CDB Instance 3CDB Instance 1
Node 2
CDB Instance 2

Soc. Sec. #
115-69-3428
DOB
11/06/71
PIN
5623
Policy
enforced redaction
of sensitive data
Oracle Redacting Sensitive Data
Mask Application Data Dynamically
Call Center
Operator
Payroll
Processing
Call Centers
Decision Support Systems
Systems with PII, PHI, PCI data

Information Lifecycle Management
• Oracle Information Lifecycle Management (ILM) is a set of automated solutions that work with the
Oracle Database to enable the usage of multi-tier storage to dramatically lower the cost of storing
application data.
• ILM combines the Oracle Partitioning technology that moves data to the appropriate storage tier
based on its activity level, with Oracle Advanced Compression to reduce the amount of disk space
data requires.
• The benefits of Oracle ILM come from the fact that it:
– Works at the database level with no application changes
– Reduces disk space requirements for all types of data
– Automates the movement of data to lower cost storage based on activity patterns
– Lowers query times by keeping only active data on high performance storage
– Increases availability to critical information on the most reliable storage

Temporal Validity
• VALID TIME rows are stored in the base table itself
• By default, queries see all rows in the table

Enterprise Manager Express 12c

What is SQL Tuning?
Introduction to SQL Tuning
SQL tuning involves the following basic steps:
• Identifying high load or top SQL statements that are responsible for a large share of the application workload and system
resources, by reviewing past SQL execution history available in the system
• Verifying that the execution plans produced by the query optimizer for these statements perform reasonably
• Implementing corrective actions to generate better execution plans for poorly performing SQL statements
• The previous steps are repeated until the system performance reaches a satisfactory level or no more statements can be tuned.
Goals for Tuning
The objective of tuning a system is either to reduce the response time for end users of the system, or to reduce the resources used to
process the same work. You can accomplish both of these objectives in several ways:
• Reduce the Workload
• Balance the Workload
• Parallelize the Workload

SQL Tuning New Features
• Adaptive SQL Plan Management
• Adaptive Execution Plan
• Optimizer Statistics Management

Heat Map
• A “Heat Map” of the Database
– Database level Heat Map shows which tables and partitions are being
used
– Block level Heat Map shows last modification at the block level
• Comprehensive
– Segment level shows both reads and writes
– Distinguishes index lookups from full scans
– Automatically excludes stats gathering, DDLs or table redefinition

Automatic Data Optimization
• Tables grow in size ILM policies
compress data
• Tablespace containing
partitions reaches ILM tiering
threshold
• Partitions are moved to
different tablespce on lower
spec disk group

Oracle Application Continuity
• Database and infrastructure outages can cause in-flight work to be lost, leaving users and
applications in-doubt
• Often leads to
 User pains
 Duplicate submissions
 Rebooting mid-tiers
 Developer pains

Unknown Transaction State
Application Servers
Database Servers
End User
Current Situation
Network Switches
User selects product from
application and purchases it from
the web checkout
User transaction arrives at
application infrastructure. It makes
it’s way through the application
tiers and results in a database
transaction being created

Application Servers
Database Servers
End User
Network Switches
application infrastructure and
makes it’s way through application
The transaction commits inside of
the database and an
acknowledgement begins it return
journey
A failure in the infrastructure on its
return journey means the
application server never receives an
acknowledgment
Current Situation

Application Servers
Database Servers
End User
Network Switches
The application is left in an
unknown state. It returns an error
to the user who may order the
product for a second time resulting
in them potentially being charged
twice.
Current Situation

Application Servers
Database Servers
End User
A reliable replay of in flight work
Network Switches
User selects product from
application and purchases it from
the web checkout
application infrastructure. It makes
it’s way through the application

Application Servers
Database Servers
End User
Network Switches The infrastructure hosting the
database fails just before the
transaction is committed to the
database.

Application Servers
Database Servers
End User
Network Switches
The jdbc driver detects the failure
and checks with an available node
in the cluster, using “Transaction
Guard”, whether the transaction
committed or needs to be replayed
If the transaction needs to be
replayed, “Application Continuity”
will submit all of the inflight work to
a surviving node in the cluster and
perform a commit. This all happens
transparently to the application

Application Servers
Database Servers
End User
Network Switches
The user receives confirmation that
his order has been successfully
completed.

Agenda
1
2
3
4
5
6

Multitenant for Development and Testing
Fast, flexible copy and snapshot of pluggable databases
Development Container Database
53
Production Container Database
GL OE AP
GL
Master
GL
(Dev2)
GL
(Dev1)

✔8
✔
SILVER
BRONZE
GOLD
✔
✔
Oracle Multitenant for Database as a Service
Pick from standard sizes and service levels
54
RAC, Data Guard
RAC
Backupssmall
large
medium
✔
8

Consolidation of Disparate Applications
Simplify, standardize, reduce risk, lower costs and upgrade SLAs with Multitenant
Scalability and High Availability Limited
Available Capacity
SILVER
Oracle Database 12c – Multitenant Container Database – Silver SLA
11g
9i
11g
10g
11g
10g
MySQL SQL Server
Oracle Conversion Utilities
55
“Deferred” Maintenance:
• Behind on Patches
• Seldom Backed Up
12c
12c
12c
12c
12c
12c
Databases
To Manage

Multitenancy implemented by the Database, not the Application
56
Oracle Multitenant for Software as a Service
Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6 Customer 7

Multitenant. Perfect for ISVs
Packaged apps and reference data are easily distributed
57
OE AP
Jolt! Applications Corporation
Development Container Database
OE AP
Customer Container Database
GL APJolt!
v7.3
Jolt!
v8.2
Jolt!
v8.2
Jolt!
v8.2
Jolt!
V7.3
Jolt!
V6.1

Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin

Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin

Similar to Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin (20)

Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin