Oracle Maximum Availability Architecture Best Practices for … · Change version and architecture in one step Data Pump/TTS tradeoffs – Big bang approach…changes version and

Oracle Maximum Availability Architecture Best Practices for Oracle Multitenant Joseph Meeks, Oracle Frank Kobylanski, Oracle Kalyan Kallepally, Wellcome Trust Sanger Institute

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 2

Program Agenda

High Availability and Oracle Multitenant

Migration Strategies

Managing Resources

Unplanned Outages and Planned Maintenance

Wellcome Trust Sanger Institute


The Promise of Multitenant

Best system utilization Most efficient management Greatest cost savings

The Better Approach to Database Consolidation


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


New Multitenant Architecture Memory and Processes Required at Multitenant Container Level Only

System Resources


OLTP benchmark comparison Only 3GB of memory vs. 20GB memory used for 50 databases

Oracle Multitenant pluggable databases scaled to over 250 while separate database instances maxed at 50

Multitenant vs Separate Databases Highly Efficient: 6x Less H/W Resource, 5x more Scalable


CRM ERP

BI HCM

DW

Consolidation from an HA Perspective High Availability is Even More Important in a Consolidated Environment


Active Data Guard – Data Protection, DR – Query Offload

GoldenGate – Active-active – Heterogeneous

Active Replica

Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate – Minimal downtime maintenance, upgrades, migrations

RAC – Scalability – Server HA

Flashback – Human error

correction

Production Site Enterprise Manager Cloud Control – Coordinated Site Failover Application Continuity – Application HA Global Data Services – Service Failover / Load Balancing

Oracle Maximum Availability Architecture

RMAN, Oracle Secure Backup – Backup to disk, tape or cloud


Single Tenant – CDB with a PDB

Unplug/Plug Ready – Future platform migration – Patching Oracle versions – Future consolidation

Completely compatible with non-CDB – No functional difference

Same performance No extra license cost

Server

CDB Instance

Services

CDB


Oracle RAC

Best for consolidation when used with Oracle Multitenant…

– Single SGA and single set of background processes per CDB instance

– More efficient, more scalable Resource Manager prevents contention

– Between different user groups and PDB’s competing for resources


Oracle Recovery Manager

RMAN backup and restore – CDB or PDB – Tablespaces and datafiles

within PDB – Point-in-time recovery at PDB

level


Active Data Guard

One Data Guard standby database One Broker/Enterprise Manager configuration

One failover/switchover command nPrimaries nStandbys

Non CDB

VS

Oracle Multitenant


GoldenGate

• Granular replication at the level of a PDB

• Consolidate, migrate and maintain

• Oracle or cross-platform • Bi-directional replication

enables phased user migration and zero downtime

Oracle 11.2 CRM

Oracle 10.2 DW

Non- Oracle ERP


Multitenant Consolidation Strategy

Step 1

• Consolidate test and development databases

Step 2

• Group production databases by HA service level

Step 3

• Consolidate production databases with like service levels


Oracle MAA Availability Tiers Availability Service Levels for Unplanned and Planned Outages

BRONZE

SILVER

GOLD Comprehensive HA and Disaster Protection Zero or Near-zero data loss

High Availability (HA) Data protected as of last backup

Single Instance Database Data protected as of last backup

PLATINUM Zero Outage for Platinum Ready Applications Zero data loss


Migration Strategies


Adopting Oracle Multitenant How Do I Migrate a Traditional Oracle Database to a CDB?

PDBs

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Non-CDBs of version DB 12.1 or later. Faster than Data Pump, simpler than GoldenGate

010010110010010010010111001001010100100101010100110101001010100100100

Plug as a PDB 12c

010010110010010010010111001001010100100101010100110101001010100100100

GoldenGate Least downtime Heterogeneous platforms

CDB

010010110010010010010111001001010100100101010100110101001010100100100

Non-CDBs of version 11.2.0.4 or earlier. Ideal for direct migration of departmental databases Downtime is a function of the number of database objects Data Pump

TTS

Non-CDBs

11g

12c 11g


Data Pump and TTS

Change version and architecture in one step Data Pump/TTS tradeoffs

– Big bang approach…changes version and architecture in one step – Scripted incremental TTS (My Oracle Support 1389592.1) – May have additional clean up steps after import – Additional manual steps if there is a Data Guard standby and using ASM

Ideal for Migrating Departmental Databases to Oracle Database 12c


Upgrade First, then Plug in as PDB

Incremental change is a more conservative approach Full database migration vs selected tablespaces Benefit from Oracle 12c RMAN enhancements available for PDB migration

– RMAN Active Database Duplication – minimal downtime with greatest simplicity Backups and incrementals are taken while source is open read-write No staging area required for backups or incrementals

– RMAN Cross Endian TTS simplifies cross-platform migration Backups and incrementals are taken while source is open read-write All operations are self-contained within RMAN, no external scripts required

Simplest way to Minimize Downtime when Migrating to PDB


For Non-CDBs Already at Oracle Database 12c Options for Migrating to Oracle Multitenant

Migrate In Place Copy Files Then Plug In Process: source set read-only, create manifest, plug in using existing files, run PDB conversion script

Process: copy files, source set read-only, create manifest, apply final incremental, plug in using new files, run PDB conversion script

Source files have been modified, fallback requires recovery Source files unchanged – easy fallback

No incremental apply required – reduces total downtime

Slightly more downtime due to final incremental apply

Space efficient, no copy required

Requires additional storage until original source database is dropped


My Oracle Support (Note 1576755.1)

Direct migration from Oracle 11.2.0.3 to PDB using Data Pump/TTS Migration from Oracle Database 12c non-CDB to PDB using RMAN

Active Database Duplication Migrating a PDB from one container to another using RMAN Active

Database Duplication Additional examples will be added over time

Detailed Migration Steps for Various Use-Cases


Migration Example: from Oracle Database 11g

① Upgrade to Oracle Database 12.1 in place ② Choose/create a target CDB ③ RMAN Active Database Duplication to

duplicate files to target CDB system ④ Iterations of RECOVER DATABASE…FROM

SERVICE until ready to migrate ⑤ Place the non-CDB into read-only mode ⑥ Generate a description file (manifest) on the

non-CDB

Upgrade to Oracle Database 12c then Plug In


Migration Example: from Oracle Database 11g

⑦ Perform final RECOVER

DATABASE…FROM SERVICE ⑧ Shutdown the non-CDB ⑨ Plug in non-CDB to CDB ⑩ Post-plug script to remove redundant

metadata for the Oracle system objects

Upgrade to Oracle Database 12c then Plug In

X


Demonstration

Start with single instance non-CDB at Oracle Database 12c Migrate to CDB as PDB with Oracle RAC and Active Standby Database Source and destination run on ASM

Go to www.oracle.com/goto/maa

Migration Walk-Through


Managing Resources


Managing Resources Between PDBs

PDBs vie for shared resources – CPU – Parallel execution servers – Sessions – I/O

Resource Manager enables policies that prioritize/manage shared resources

– Set hard limits in consolidated environment – ‘get what you pay for’


An Example - Managing CPU

CDB Resource Plan

PDB Shares Utilization Limit Guaranteed CPU (share)

Maximum CPU (limit)

Sales 2 2/4 = 50% 100%

Marketing 1 75% 1/4 = 25% 75%

Support 1 75% 1/4 = 25% 75%

“Utilization limits” are used to enforce a hard limit on the CPU

usage for a PDB

“Shares” are used to specify how CPU is

distributed between PDBs

Marketing Support Sales

Container Database

25% min 25% min 50% min 75% max 75% max 100% max



Container Database

25% min 25% min 50% min 75% max 75% max 100% max


With a utilization limit of 75%, SUPPORT is throttled, even

though CPU is available.

0

10

20

30

40

50

60

70

80

90

100

CPU Utilization Support (1 share)

Marketing (1 share) Sales (2 shares)

Utilization Limits provide clients consistent performance. They also restrict their resource usage, based on what the client paid

With Support and Marketing active, each gets an equal share

When all workloads are active, they again share the CPU based

on their ratio of shares.




CDB Resource Plan

PDB Shares Utilization Limit Guaranteed CPU

Maximum CPU

(Default directive) 1 50% 1/n 50%

Sales 2 2/4 = 50% 100%

Marketing 1 75% 1/4 = 25% 75%

Support 1 75% 1/4 = 25% 75%

Configure a “default directive” that automatically applies share and

utilization limits for subsequent PDBs. Future PDB

Container Database

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 31 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Enterprise Manager 12c and Oracle Multitenant

Life Cycle Management

Management

Planning, Testing,

Migration

Consolidation

Proactive and Real-Time QoS Management

Quality of Service

0%

20%

40%

60%

80%

100%

120%

Database as a Service,

Rapid Cloning

Self-Service IT


Unplanned Outages and Planned Maintenance


Active Data Guard – Data Protection, DR – Query Offload

GoldenGate – Active-active – Heterogeneous

Active Replica

Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate – Minimal downtime maintenance, upgrades, migrations

RAC – Scalability – Server HA

Flashback – Human error

correction

Production Site Enterprise Manager Cloud Control – Coordinated Site Failover Application Continuity – Application HA Global Data Services – Service Failover / Load Balancing

Oracle Maximum Availability Architecture

RMAN, Oracle Secure Backup – Backup to disk, tape or cloud


Unplanned Events Proactively Minimize or Eliminate Downtime

Event Primary Solutions

Site failure Data Guard

Instance or server failure Oracle RAC

Storage failure Automatic Storage Management (ASM), RMAN

Data corruption Oracle Database parameters, Active Data Guard

Human error Flashback (CDB), RMAN point in time recovery (CDB or PDB)

Performance Database Resource Manager


What Happens if a PDB is in Trouble

Use Resource Management to limit impact to other PDBs while problems are resolved If unable to resolve or the solution has the potential to impact

other PDBs then: – Unplug and plug into its own CDB and resolve – Once resolved unplug and plug back into the original CDB

And the CDB and all Other PDBs are Healthy


If Database Needs Recovery

Backup/restore – Entire CDB – PDB in isolation of other PDBs

Point in time recovery – CDB – all PDBs move back to same point in time – Individual PDB – no impact to other running PDBs

Clone CDB and a subset of PDB Demonstration – Point in time recovery for PDB at www.oracle.com/goto/maa

RMAN and Multitenant


Planned Maintenance Minimize or Eliminate Scheduled Downtime

Event Primary Solutions

Migrations UnPlug/Plug, Data Pump/TTS, GoldenGate

Data reorganization Online Reorganization and Redefinition

Patching and upgrades Online Patching, UnPlug/Plug, Rolling Upgrades

Application upgrades Edition-Based Redefinition, GoldenGate


Manage as One: Upgrade in Place Apply Changes Once, All Pluggable Databases Updated

Upgrade in-place


Flexible Upgrade of Individual PDBs Unplug/Plug


Manage as One - Minimal Downtime Upgrades Active Data Guard Database Rolling Upgrade

Data Guard

Step 1: Defer redo transport



Data Guard

Step 2: Upgrade standby and resync with primary



Step 3: Switch production to new version – only downtime



Data Guard Data Guard

Finish: Mount original primary in new home and resync


Flexible Zero Downtime Upgrade for a PDB Oracle GoldenGate

GoldenGate bi-directional replication across versions


Summary – Multitenant and Oracle MAA

Flexible migration strategies Policy-driven resource management HA and data protection optimized for Oracle Reduced complexity while retaining flexibility

– Manage as one at a CDB level – Operate on an individual PDB where

it makes sense to do so

High Availability and Data Protection

Oracle Database 12c

at Wellcome Trust Sanger Institute (WTSI)

Oracle Open World - 2013

Kalyan Kallepally Principal Database Administrator

About Me • Working as Principal Database Administrator at

– Wellcome Trust Sanger Institute • 12 years of experience in Oracle (8-11gr2) • 6 years of experience in MySQL, SQL Server & PostgreSQL • Active member in 12C beta testing program • Recently started blogging

– www.dbakalyan.wordpress.com – You can reach me on [email protected]

http://www.dbakalyan.wordpress.com/�

mailto:[email protected]�

Wellcome Trust Sanger Institute

• One of the leading and most published genome institutions in the world

• Located in Hinxton, south of Cambridge, UK

• Founded in 1993 by the Wellcome Trust and the UK Medical Research Council (MRC)

• Primarily funded by the Wellcome Trust

• The institute is named after Dr Fred Sanger – The double Nobel prize-winning biochemist

• Main aim is to ensure scientific data is freely available

• Responsible for the completion of 1/3 of the human genome

Data Centre at WTSI • 1000m2 of Datacentre space split into

4 quadrants

• Current computational capacity - 16.5K cores and 20PB of storage

• 24/7 reliability with DR setup

• Going Green initiative – Implemented Virtualization, MAID storage, data compression using algorithms and storage solutions

• Power consumption constant at 1.2MW since May 2009 despite 20 fold data storage increase

WTSI Oracle Grid Infrastructure - 11gR2 • Primary Site 2 X 4 Node RAC clusters 2 Node RAC Cluster Oracle Restart Nodes

• DR Site 4 Node RAC cluster Oracle Restart

WTSI Data Guard Layout

Physical Standby Database

Primary Database

11.2.0.2

Sync or Async Redo shipping

Sync or Async Redo shipping

Local Site

DR Site

Read Write Clients Read Only Clients

ASM

ASM

ASM

Broker

Backup

Redo apply

Oracle Home (11.1.0.6)


Oracle Home (11.1.0.6) Oracle Home (11.2.0.2)

Oracle Home (11.2.0.2) Physical Standby Database

11.2.0.2 Redo Logs

Redo apply

Redo Logs

Online Redo Logs


11.2.0.2

Current Projects • Cancer Genome Project (CGP) – Sanger Institute is a world leader in using DNA sequencing to identify

mutations that causes cancer. – Make the scientific data available to the world via our websites 24x7 – Multiple database deployments to support both laboratory and

research websites

• Laboratory Information Management System (LIMS) – 24x7 multi-user laboratory information system designed to track and

manage the efficient genotyping, phenotyping and production of model organisms for the purpose of scientific study

– Backend databases play a vital role In supporting the system – We provide DaaS & SaaS to scientific collaborators around

the world

Data Guard

4 Node 4 Node

WAN TRAFFIC

Clients

Dedicated Network

Primary Site DR Site

+ASM1 +ASM2 +ASM3 +ASM4 +ASM1 +ASM2 +ASM3 +ASM4

Cancer Genome Project - Current RAC/GRID Layout (11gR2)

LIMS – Current Virtualization One-to-One Standby Layout (11gR2)

Primary Site DR Site VMware

Fire wall WAN

Host O/S Guest O/S

Oracle home Guest O/S

Oracle home DB1 DB2

Guest O/S Oracle home


DB3 DB4



DB5 DB6



DB7 DB8



DB9 DBn

Host O/S Guest O/S


Oracle home DB1 DB2



DB3 DB4



DB5 DB6



DB7 DB8



DB9 DBn

VMware Active Data Guard

Current Challenges • Databases in consolidated environments compete for

shared computing resources CPU, memory, sessions, parallel execution servers, I/O

• Provisioning and management of many discrete databases Cloning Managing a large number of virtual environments Managing large number of standbys for HA Backups

• Patching and upgrading Oracle database/software binaries Many dependencies

12c Optimal Solution to Current Challenges

“Multitenant Architecture”

Primary Site DR Site VMware

Fire wall WAN

Host O/S Guest O/S


Oracle home DB1 DB2



DB3 DB4



DB5 DB6



DB7 DB8



DB9 DB10

Host O/S Guest O/S


Oracle home DB1 DB2



DB3 DB4



DB5 DB6



DB7 DB8



DB9 DB10

VMware Active Data Guard

LIMS Today - Virtualization and One-to-One Standby Layout (11gR2)

Primary Site

Fire wall WAN

Active Data Guard

DR Site Oracle Multitenant

Oracle Multitenant

Host O/S

PDB1 PDB2

Oracle home

PDB3 PDB4

PDB5 PDB6

PDB7 PDB8

PDB9 PDB10

Container Database

Host O/S

PDB1 PDB2

Oracle home

PDB3 PDB4

PDB5 PDB6

PDB7 PDB8

PDB9 PDB10

Container Database

LIMS – Using Oracle Multitenant with Oracle Database 12c

Active Data Guard

4 Node 4 Node

WAN TRAFFIC

Clients

Dedicated Network



CGP – Current RAC/GRID Layout (11gR2)

Active Data Guard

4 Node 4 Node

WAN TRAFFIC

Clients

Dedicated Network



Global Data Services Application continuity

• Only two container databases • More efficient resource utilization

• Same RAC Advantages • Manage as one

• Backups and standbys • New PDBs replicated automatically • Move, Upgrade & Patch

CGP – Oracle Multitenant (12C) with RAC

A Smarter way to Consolidate • More efficient resource utilization

– Higher density and greater scalability

• Manage many databases as one – Manage, upgrade & patch

• Backups are done at the container level

– Backed up as one, flexibility to restore & recover at PDB level

• Standby is configured at CDB level – All PDB’s with in CDB are automatically replicated

Summary

Looking forward to life with Oracle Database

12c at WTSI


Resources


Links

www.oracle.com/goto/maa http://www.oracle.com/us/products/database/options/multitenant/

overview/index.html

@OracleMAA

http://www.oracle.com/goto/maa�

http://www.oracle.com/us/products/database/options/multitenant/overview/index.html�

http://www.oracle.com/us/products/database/options/multitenant/overview/index.html�


Multitenant Migration Options - Summary

Source Version Migration Method Considerations If Data Guard Standby Downtime Estimate

12c same endian migration of non-CDB

RMAN Active Duplication

• Requires no staging area for backups

• Incremental method (only downtime is the final incremental apply)

• Copy files to standby using same RMAN Active Duplication functionality

• MRP continues

<1hr impacted by time for last incremental and time required for noncdb_to_pdb.sql execution

12c same endian unplug/plug of PDB

RMAN Active Duplication

• Requires no staging area for backups

• Incremental method

• Copy files to standby using same RMAN Active Duplication functionality

• MRP continues

15m, impacted by time for last incremental and time required for dbms_pdb.sync_pdb execution

12c cross endian migration of non-CDB or PDB

12c RMAN Incremental XTTS

• Requires a seed PDB to be precreated prior to datapump import

• Requires staging area for backups

• Incremental method

• Copy files to standby using same functionality

• Follow Data Guard documentation for handling the datafiles

30m, impacted by time for last incremental and time required for datapump metadata import


Multitenant Migration Options - Summary Source Version

Migration Method Considerations If Data guard standby Downtime Estimate

11.2.0.3 Any endian

Data Pump Full Database TTS/XTTS

• Datapump import to plug in tablespaces

• Requires a seed PDB to be precreated prior to Data Pump import

• Incremental method available

• Copy files to standby using ASMCMD cp or host based copy command


Impacted by time for last incremetnal and time required for Data Pump metadata import

Other 11g and 10g Any endian

Data Pump TTS/XTTS







Other 11g and 10g Any endian

Data Pump TTS/XTTS







Any version, Any endian

GoldenGate

• Requires a seed PDB to be precreated prior to GoldenGate instantiation

• Zero downtime migration requires bi-directional replication

• Instantiation of GoldenGate objects on primary may require additional steps to maintain standby

Minimal or Zero


Graphic Section Divider

Documents

Oracle Maximum Availability Architecture Best Practices for … · Change version and architecture in one step Data Pump/TTS tradeoffs – Big bang approach…changes version and