what’s new in database onsolidation · what’s new in database onsolidation ... backup databases...

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

What’s New in Database Consolidation

Eric Cohen Solution Architect


Safe Harbor Statement

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 Confidential – Internal/Restricted/Highly Restricted 2


Agenda

Rethinking Architecture for the Database Cloud

Multitenant Architecture

Capabilities Enabled

Managing Shared Resources

Upgrading to Multitenant

Use Cases


Business Drivers Customers facing great pressure to consolidate databases in cloud

Requirements • Tenant isolation • Easy adoption • Manage many as one • Retain granular control

Economic Pressures Operational Pressures

Consolidate to cut costs • Reduce power • Reduce floorspace • Reduce licenses

Deliver cloud-based agility • Self-service • Rapid provisioning • Simplified management


Database Consolidation on Clouds Traditional consolidation methods

Consolid

atio

n D

ensity

Schema Consolidation

share servers, OS & database

Virtual Machines

share servers

Stacked Databases

share servers & OS


Consolid

atio

n D

ensity

Oracle Multitenant Simplifies consolidation, enables Database as a Service

share servers, OS & database

Pluggable Databases Stacked Databases

share servers & OS

Virtual Machines

share servers


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


Agenda






Use Cases


Multitenant Architecture Components of a Multitenant Container Database (CDB)

Pluggable Databases (PDBs)

PDBs

Root

CDB



• 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

Database Link


A Pluggable Database is a Portable Database Unplugging a PDB and plugging it in

• 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 Example

alter pluggable database HCM

unplug into '/u01/app/oracle/oradata/…/hcm.xml'

create pluggable database My_PDB

using '/u01/app/oracle/oradata/…/hcm.xml'

Plug

Unplug


Common Data Dictionary Before 12.1: Oracle and user data intermingle over time

Database Created

Data D

ictio

nary

User Data

Meta D

ata

Mature Database

Data D

ictio

nary

User Data

Meta D

ata

Tables, Code, Data added

Data D

ictio

nary

User Data

Meta D

ata


OBJ$ TAB$ SOURCE$

…

Oracle Data and User Data

OBJ$ TAB$ SOURCE$

…

EMP DEPT

…

OBJ$ TAB$ SOURCE$

…

Multitenant fix:

Horizontally-partitioned data

dictionary

Only Oracle system definition

remains

Oracle and customer

metadata intermingled


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”

In-database virtualization


Multitenant Scalability

• Only small increments in memory as additional PDBs are added

0

0.5

1

1.5

2

2.5

3

CRM HCM ERP

GB

Pluggable Database

MEMORY

0

0.5

1

1.5

2

2.5

3

CRM HCM ERP BI

GB

Pluggable Database

MEMORY

0

0.5

1

1.5

2

2.5

3

CRM HCM ERP BI DW

GB

Pluggable Database

MEMORY


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 Upgrades Apply changes once, all pluggable databases updated

Upgrade

in-place


Multitenant for Patching Flexible choice when patching & upgrading databases


Expand Cluster to Support Flexible Consolidation Model

Services

Single SGA per CDB Instance

Improved Agility With Changing Workloads

Node1

CDB Instance 1

Node2

CDB Instance 2

Multitenant Container Database (CDB)


Expand Cluster to Support Flexible Consolidation Model

Services

Single SGA per CDB Instance

Node1

CDB Instance 1

Node2

CDB Instance 2

Node3

CDB Instance 3

Improved Agility With Changing Workloads

Multitenant Container Database (CDB)


GOLD

SILVER

BRONZE

RAC, Data Guard, Daily Incrementals

Data Guard, Daily Incrementals

Weekly Full Backups

PDB migrates through SLAs as it becomes more mission critical

Unprecedented Agility with Pluggable Portability


Multitenant for Rapid Provisioning Pluggable databases can be quickly provisioned from seed

0

5

10

15

20

25

Non CDB PDB Clone PDB using Copy-on-WriteFile System

Time Taken to Provision New Database


Multitenant for Rapid Provisioning

PDBs can be cloned from remote CDBs

PDBs can be cloned from within the same CDB

Fast cloning of PDBs

Thinly provision snapshot clones in seconds


Cloning and creating a PDB

create pluggable database PDB2 from PDB1@CDB2

Provision a remote full clone

create pluggable database PDB3

admin user PDB_Admin identified by p

roles = (DBA)

Provision a new PDB

create pluggable database PDB2 from PDB1

snapshot copy

Thinly provision a local snapshot clone


Provisioning & Storage Gains with Snapshots

Full Size (GB) Full Clone

24 9 min, 52 sec

216 1hr, 21 min

1300 9hr, 7 min

Internal Tests on Sun ZFS Storage Appliance


Provisioning & Storage Gains with Snapshots

Full Size (GB) Snap Size (KB) Relative Size Full Clone Snap Clone % Savings

24 140 0.00058% 9 min, 52 sec 1 min, 52 sec 80%

216 142 0.00007% 1hr, 21 min 2 min, 11 sec 97%

1300 551 0.00004% 9hr, 7 min 5 min 55 sec 99%

Internal Tests on Sun ZFS Storage Appliance


Traditional File System Full copy duplicates all data blocks

my_file

my_file_copy File is collection of data blocks And headers Copy duplicates header & data blocks

Effective & simple, but expensive!

cp my_file my_file_copy


Copy-on-Write Basics Much more efficient storage of substantially similar files

my_file

my_file_copy

File is collection of data blocks And headers Copy file requires only copy of header

Much more efficient storage Minimal IO to create copy



Copy-on-Write Basics Much more efficient storage of substantially similar files

my_file

my_file_copy

File is collection of data blocks And headers Copy file requires only copy of header

Much more efficient storage Minimal IO to create copy

Copy block only when change needed



Per PDB vs per CDB Common operations on CDB with granular control where appropriate

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


Advantages of Multitenant Architecture Reduced CapEx & OpEx, Increased Agility, Easy Adoption

Self-contained PDB for each application Applications run unchanged Rapid provisioning (via clones) Portability (via pluggability)

Shared memory and background processes More applications per server

Common operations performed at CDB level Manage many as one (upgrade, HA, backup) Granular control when appropriate


Agenda






Use Cases


Managing Shared Resources Resource management in multitenant environment

High Priority

Medium Priority

Low Priority


Managing Resources between PDBs

• Using Resource Manager, you can control

– CPU

– Exadata I/O

– Sessions

– Parallel execution servers

• Simple-yet-powerful policies configured in terms of:

– A number of shares allocated to each PDB

– A “cap” (a.k.a. maximum utilization limit) may be applied to each PDB


Manage CPU

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%

2 Shares 1 Share 1 Share

A CDB Resource Plan uses

shares to specify how CPU is

distributed between PDBs


Agenda






Use Cases


Upgrading to Multitenant Step 1: Upgrade databases in-place

Upgrade in Place


Upgrading to Multitenant Step 2: Plug-in upgraded databases



• No application changes required.

Step 3. Change applications to work with Multitenant Step 3. Change applications to work with Multitenant


Migrate using Replication

① Provision new PDB 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.)


Agenda






Use Cases


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


2. Consolidation of Disparate Applications Shared overhead of memory and processes

System Resources


RAC, Data Guard

Data Guard

3. Self-Service Database as a Service (DBaaS) Pick from standard sizes and service levels

GOLD

SILVER

BRONZE Backups


3. Self-Service Database as a Service (DBaaS) Trivially migrate tiers as databases become more mission critical

GOLD

SILVER

BRONZE

RAC, Data Guard

Data Guard

Backups


4. Multitenant. Perfect for SaaS. Multitenancy implemented by the Database, not the Application


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


6. Analytics Sandbox Provisioning Fast, flexible copy of isolated data marts for analysis in-memory


Use Cases

1. Development / Testing – start here!

2. Consolidation of Disparate Applications

3. Database as a Service (DBaaS) on Private Cloud

4. Software as a Service (SaaS)

5. ISVs: Distribution of Packaged Apps and Data

6. Analytics Sandbox Provisioning

7. …many others!


Partners Support Oracle Multitenant


First Multitenant Production Customer Motivated by provisioning & cloning

• Consolidation from Amazon RDS & dedicated servers

• Benefits

– Cloning: huge benefit to testing & much faster roll out

– Reduced Cost : offset hardware costs & hosting/Amazon costs

– Management :

• adding new clients has reduced our mgmt overhead

• service desk have no additional work with each PDB


Oracle Internal Multitenant Deployment • April 2013: Two production databases consolidated using 12.1 Beta

• July 2013: Moved to 12.1 Production using unplug/plug

• Ongoing:

– Additional existing databases consolidated

– New databases provisioned


Benefit Capability Enabled

Minimize CapEx • More applications per server

Minimize OpEx • Manage many as one • Standardized procedures & service levels • Cloning for development / testing

Maximize Agility • Rapid provisioning • Portability through “pluggability” • Scalability with RAC

Easy • To Adopt: Applications run unchanged • To Use: Interface is SQL

Key Benefits

what’s new in database onsolidation · what’s new in database onsolidation ... backup databases...

Documents