oracle multitenant - organized by orient itm - 12 jul 2014

Oracle MultitenantMahir M. Quluzade

Insert Picture Here

Organized by ORIENT ITM 12 July 2014

2 Oracle Multitenant - Mahir M. Quluzade © 2014 http://www.mahir-quluzade.com

Agenda

Rethinking Architecture for the Database Multitenant Architecture Capabilities Enabled Managing Shared Resources Upgrading to Multitenant


About me

Broad member of AZEROUG (Azerbaijan Oracle User Group) OCE, RAC 11g and Grid infrastructure OCP Database 11g Administrator OCE Database SQL Author of OTN Articles and OTech Magazine Central Bank - Oracle DBA Oracle Blog : http//www.mahir-quluzade.com


Oracle Database Architecture

Oracle Instance– SGA & PGA – Background Processes

Oracle Database – Control Files– Data Files – Redo Logs (Online and Archived)– Parameter and Password file

Pre-12c Oracle Database

Database ServerMemory

BackgroundProcesses

DatabaseFiles


Oracle Database ArchitectureRequires memory, processes and database files

System Resources

ERPMemory

BackgroundProcesses

DatabaseFiles

CRMMemory

BackgroundProcesses

DatabaseFiles

DWMemory

BackgroundProcesses

DatabaseFiles


Container Database

New Multitenant ArchitectureMemory and processes required at multitenant container level only

System Resources

ERPMemory

BackgroundProcesses

DatabaseFiles

CRMMemory

BackgroundProcesses

DatabaseFiles

DWMemory

BackgroundProcesses

DatabaseFiles


New Multitenant ArchitectureMemory and processes required at multitenant container level only

System Resources

Container Database


Increasing ConsolidationOracle Database 12g

Schema Consolidation

Container Database

Multitenant Database


Agenda

Rethinking Architecture for the Database Multitenant Architecture Capabilities Enabled Managing Shared Resources Upgrading to Multitenant


Multitenant ArchitectureComponents of a Multitenant Container Database (CDB)

Multitenant Container DatabaseROOT

12.1

HCM12.1

DW12.1

CRM12.1

ERP12.1

Pluggable Databases (PDBs)

PDBs

Root

CDB

create database … enable pluggable database

Create CDB

create pluggable database …Create PDB


Multitenant Architecture

Multitenant architecture can currently support up to 252 PDBs

A PDB feels and operates identically to a non-CDB

You cannot tell, from the viewpoint of a connected client, if you’re using a PDB or a non-CDB

Database Link


Unplug / plugSimply unplug from the old CDB…


Unplug / plug

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

…and plug in to the new CDB…


Unplug / plugExample

alter pluggable database HCMunplug into '/u01/app/oracle/oradata/…/hcm.xml'

create pluggable database My_PDBusing '/u01/app/oracle/oradata/…/hcm.xml'

Plug

Unplug


Common Data DictionaryBefore 12.1: dilution over time

Database Created Mature DatabaseTables, Code, Data added


Data Dictionary Architecture in a CDBOracle Database 12c

OBJ$ TAB$ SOURCE$

…

EMP DEPT

…

OBJ$ TAB$ SOURCE$

…

rootDatabase Metadata Only

PDBUser Metadata Only User Data

Met

adat

a Li

nks

Oracle Database stores metadata about dictionary objects only in the root

– PDB uses Metadata Link to point to the definition of object stored in the root

The data corresponding to a metadata link resides in its PDB


Multitenant Architecture – Dynamics

PDBs share common SGA andbackground processes

Foreground sessions see only the PDB they connect to


CRM HCM ERP BI0

0.51

1.52

2.53

MEMORY

Pluggable Database

GB

CRM HCM ERP BI DW0

0.51

1.52

2.53

MEMORY

Pluggable Database

GB

Multitenant Scalability

Only small increments in memory as additional PDBs are added

CRM HCM ERP0

0.51

1.52

2.53

MEMORY

Pluggable Database

GB


Files in the CDB

Each PDB has its own set of tablespaces including SYSTEM and SYSAUX

PDBs share UNDO, REDOand control files, (s)pfile

By default the CDB has a single TEMP tablespace but PDBs may create their own

Namespaces


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


Common Users and Privileges

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 privilegecommonly – 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

Authorization is checked in the same way as as pre-12.1


Agenda

Rethinking Architecture for the Database Cloud Multitenant Architecture Capabilities Enabled Managing Shared Resources Upgrading to Multitenant


Manage Many as One with MultitenantBackup databases as one; recover at pluggable database level

DW12.1

CRM12.1

ERP12.1

One Backup

Point-in-time recoveryAt pluggable database level

Multitenant Container Database


Production Container Database

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

HCM12.1

DW12.1

CRM12.1

ERP12.1

Standby Container Database

HCM12.1

DW12.1

CRM12.1

ERP12.1


Multitenant for Simplified PatchingApply changes once, all pluggable databases updated

Upgrade in-place

Multitenant Container Database

DW12.1

CRM12.1

ERP12.1

12.X

12.X

12.X


Multitenant for UpgradesFlexible choice when patching & upgrading databases

Original Container Database (12.1) Upgraded Container Database (12.X)

DW12.X

CRM12.X

DW12.1

CRM12.1

ERP12.1


Improved Agility With Changing WorkloadsExpand Cluster to Support Flexible Consolidation Model

Services

Single SGA perCDB Instance

Node1

CDB Instance 1

Node2

CDB Instance 2

Multitenant Container Database (CDB)

CRMBI HCM ERPDW


Improved Agility With Changing WorkloadsExpand Cluster to Support Flexible Consolidation Model

Services

Single SGA perCDB Instance

Node1

CDB Instance 1

Node2

CDB Instance 2

Node3

CDB Instance 3

Multitenant Container Database (CDB)

CRMBI HCM ERPDW


Multitenant for Provisioning

PDBs can be cloned from remote CDBs

PDBs can be cloned from within the same CDB

Fast cloning of PDBs


Cloning a PDBExample

create pluggable database HCMBI from HCM

create pluggable database HCMBI from [email protected]

Remote (DB Link)

Local


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

Single Oracle Software Version

Data Guard

Scheduled RMAN Backups

Some parameters/propertiese.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 ArchitectureReduced CapEx & OpEx, Increased Agility, Easy Adoption

Container Database

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



Managing Shared ResourcesResource management in multitenant environment

Multitenant Container DatabaseHigh Priority

Medium Priority

Low Priority

DW

CRM

ERP


Managing Resources between PDBs

Resource Manager can manage resources on two basic levels:– CDB level

How resources are allocate d to PDBs Limit the resources utilization of specific PDBs

– PDB level Resource Manager can manage the workloads within each PDB


Managing Resources between PDBs

Using Resource Manager, you can control– CPU– Parallel execution servers– Exadata I/O– Sessions

Configure a policy that controls how resources are utilized– Default configuration that works, even as PDBs are added or removed

You can change default configuration


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



Upgrading to MultitenantStep 1: Upgrade databases in-place

10.2

ERP

11.1

CRM

11.2

DW

12.1

ERP

12.1

CRM

12.1

DW

Container Database

Upgrade in PlaceContainer Database


Upgrading to MultitenantStep 2: Plug-in upgraded databases

Container Database

12.1

ERP

12.1

CRM

12.1

DW


Upgrading to Multitenant

No application changes required.

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.)


Benefit Capability Enabled

Minimize CapEx • More applications per server

Minimize OpEx• Manage many as one• Standardized procedures & service levels• Rapid provisioning

Maximize Agility• Cloning for development / testing• Portability through “pluggability” • Scalability with RAC

Ease of Adoption • Applications run unchanged

Key Benefits


Agenda



Q&AYour questions


Thank you!

Mahir M. Quluzadehttp://www.mahir-quluzade.com

ORIENT ITM!

oracle multitenant - organized by orient itm - 12 jul 2014

Technology

agenda rethinking

multitenant

multitenant

local user

common role

common user

granular control

improved agility