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

Co

nso

lidat

ion

Den

sity

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

Co

nso

lidat

ion

Den

sity

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


AP OE GL

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


Multitenant Architecture 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.1 12.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

Upgrading to Multitenant 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

Upgrading to Multitenant 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 Multitenant Step 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

OE GL


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 3 CDB 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

User transaction arrives at application infrastructure and makes it’s way through application tiers and results in a database transaction being created

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

Unknown Transaction State 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.

Unknown Transaction State Current Situation


Oracle Application Continuity

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

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 The infrastructure hosting the database fails just before the transaction is committed to the database.

Oracle Application Continuity A reliable replay of in flight work


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

Backups small

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

SILV

ER

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 AP Jolt!

v7.3

Jolt!

v8.2

Jolt!

v8.2

Jolt!

v8.2

Jolt!

V7.3

Jolt!

V6.1

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 58

Documents

Multitenant Full Deck Jan 2015 Cloud Team AJ Linkedin