Maximum Availability With Multi Tenant Database

Maximum Availability with Oracle Multitenant: Seeing Is Believing

Frank Kobylanski Principal Member of Technical Staff Oracle Maximum Availability Architecture Joseph Meeks Senior Director, Product Management Oracle High Availability Systems

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


Program Agenda

Oracle Multitenant

Isolation during Upgrades and Maintenance

Isolation from Data Corruptions

Isolation from Runaway Workloads

Wrap-up and Resources

1

2

3

4

5

2


Evolution in Consolidation Strategies for Oracle Database

3

DB7

Oracle home Guest O.S.

DB4


DB3


DB1


DB8


DB6


DB4


DB2


Host Operating System

First Generation

Virtualize the Machine Second Generation

Virtualize the Database


PDBn

PDB10

PDB8

PDB6

PDB3

PDB2

PDB11

PDB9

PDB7

PDB5

PDB3

PDB1

Oracle Home Container Database


The Oracle Multitenant Architecture

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

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

For Database Consolidation Oracle Multitenant Benefits

Benefit Capability Enabled

Minimize CapEx • More applications per server

Minimize OpEx • Manage many as one

Maximize Agility • Portability through “pluggability”

Easy • Applications run unchanged


HA Implications of Consolidation onto Shared Infrastructure

6

PDB2

PDBn

PDB3 PDB1

Multitenant Container Database


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

Active Data Guard – Data Protection, DR – Query Offload

GoldenGate – Active-active replication – Heterogeneous

Active Replica

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

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

RAC – Scalability – Server HA

ASM – Local storage

protection

Production Site

Flashback – Human error

correction

Oracle Maximum Availability Architecture (MAA)


MAA Benefits for Oracle Multitenant


High Availability • Capabilities to achieve any RTO objective

Data Protection • Zero data loss protection at any distance

Reliable Performance • Dynamic workload management

High ROI • All components active

8

At the Container level


Additional HA Implications

9

Of Consolidation onto a Shared Infrastructure

PDB 2

PDB 3

PDB 1 PDB 4 PDB 7

PDB 8 PDB 5

PDB 6 PDB n

PDB 5


MAA Benefits for Oracle Multitenant


High Availability • Unplug/plug of a PDB for any purpose is transparent to other PDBs

Data Protection • Backup and recovery at a PDB level

Reliable Performance • Dynamic management of resources at a PDB level ensures reliable service while efficiently utilizing all available capacity

High ROI • All components active

10

At the PDB level


Program Agenda

Oracle Multitenant





1

2

3

4

5

11


Upgrades and Maintenance

Method Planned Downtime

Manage Many as One – Upgrade CDB to upgrade all PDBs in a single task Downtime is a function of the number of PDBs

Unplug-plug – Upgrade one or more PDBs without affecting other PDBs 30-60 minutes

Data Guard Rolling Upgrade of an entire CDB Less than 60 seconds

GoldenGate Zero Downtime upgrade of CDB or individual PDBs Zero

12

Flexible Options for Any Service Level


Upgrade a PDB from 12.1.0.1 to 12.1.0.2, Other PDBs Run Unaffected Demonstration Overview

14

Choose a PDB in a 12.1.0.1 container for upgrade

Run pre-upgrade SQL against the 12.1.0.1 PDB

15

12.1.0.2 pre-upgrade script

Unplug from 12.1.0.1 container

16

Plug in to 12.1.0.2 container

17

Error signals that PDB still needs to be upgraded

18

Run upgrade script for the PDB

19

Script completes, version error is resolved

20

Open PDB in new release

21

Complete post-upgrade tasks

22


Program Agenda

Oracle Multitenant





1

2

3

4

5

23


Oracle-Aware Data Protection

Type Scheduled Runtime

Physical block consistency

• Dbverify, Analyze, RMAN, ZDLRA, Exadata

• Oracle Database in-memory checks, ASM, Data Guard and Exadata automatic HARD disk scrub

Logical inter-object consistency • Analyze • Cross object validations, e.g. table rows to index

entries

Logical intra-block consistency

• Dbverify, Analyze, ASM, RMAN, ZDLRA, Exadata

• Oracle Database in memory checks, Data Guard and Exadata

Logical lost-write corruptions

• Data Guard

Automatic repair • Oracle Database auto repair in-memory corruption • ASM, Active Data Guard and Exadata auto repair on-

disk physical corruptions

24


Recover at a PDB Level - Without Affecting Other PDBs

• RMAN backup/restore – One backup protects a CDB and all of its PDBs – PDBs can also be backed up in isolation

• RMAN point in time recovery – CDB: all PDBs recovered to same point in time – PDBs: individual PDB can be recovered with no

impact on other PDBs

• Clone at either CDB or PDB level

Using RMAN with Oracle Multitenant


Demonstration Overview

• A container with three active PDBs • One of the PDBs is impacted by data corruption • RMAN is used to repair the PDB • The two adjacent PDBs continue to run unaffected

26

PDB Recovery in Isolation from other PDBs

A container with 3 PDBs and swingbench workload

Single online backup of entire container

28

Connect to FRANKPDB2 and query a table

29

Query completes successfully

30

Corruption induced - second query signals ORA-01578 Other PDBs continue processing

31

Recover the data file for the affected PDB Other PDBs continue processing

32

Restore completes, re-run query

33

Repair is confirmed

34


Program Agenda

Oracle Multitenant





1

2

3

4

5

35


Managing Resources Between PDBs

• PDBs vie for shared resources – CPU – Parallel execution servers – Sessions – I/O (Exadata only management)

• Resource Manager enables policies that prioritize/manage shared resources – Set hard limits in consolidated environment – Control run-time access to available capacity – Provide “get what you pay for” service levels


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



• Begin with: – A standalone database with average workload that consumes 11 CPUs – A container database with 2 active PDBs that have been allocated a total of 24 CPUs. On average they

consume 16 CPUs.

• Knowingly oversubscribe by migrating the standalone database into the existing CDB

• Modify the active resource plan to limit CPU consumption by the new PDB – The original 2 PDBs still get the capacity required to achieve their expected service levels – The new PDB has its resource consumption throttled

• Either accept reduced throughput or pay for additional CPU

38

PDB Isolation from Run-Away Workloads

Active Database in Standalone Environment • Average throughput = 2,300 TPS • Average CPUs = 11

39

A CDB with Two PDBs

40

• PDB001 – Average throughput = 2,200 TPS – Average CPUs = 10

• PDB002 – Average throughput = 1,600 TPS – Average CPUs = 6 CPU

41

Defined for the Existing PDB’s with Default for New PDBs The Active Resource Plan for the Container Database

Consolidate the Standalone Database

42

2. Plug in and convert to PDB

3. Open the PDB

1. Create manifest

43

The new PDB has been assigned the default plan View the Active Resource Plan

Create an Explicit Resource Allocation for OOW001PDB

44

45

The New PDB is Constrained

PDB Average CPU Before After

Average TPS Before After

OOWOO1 11 6 2300 1500

PDB001 10 9 2200 2000

PDB002 6 5 1600 1500

Original PDB CPU Usage is Slightly Changed



• Begin with 2 standalone databases. One is idle, the second utilizes all of its allocated capacity

• Consolidate the 2 databases as PDBs in the same container – Allocate less capacity than the total that was allocated in their standalone environments – Set a resource plan using shares and limits – The more active database automatically benefits from the shared resources of the CDB.

• Increase workload on the busier PDB and observe how capacity is dynamically allocated up to its resource limit.

• Increase workload on the idle PDB and show how capacity is automatically shifted back according to its resource share.

46

Enable Controlled Runtime Access to Shared Resources

Heavily Loaded Standalone Database – OOW002

• Average throughput = 2,100 TPS • Average CPU = 12

47

Lightly loaded database with 10 idle CPU’s – OOW003

48

• Average throughput = 200 TPS • Average CPU = 2

Create Manifest, Plugin and Convert, Open the PDBs

49

Create a Resource Plan

50

Select PDBs to be Assigned Resource Allocations

51

Set Shares and Limits

52

Activate the Plan

53

54

Reduce Total CPU Allocation from 24 to 18 Two PDBs in Same Container



OOW002 12 11 2100 2200

OOW003 2 2 200 200

55

Total CPU Allocation Unchanged at 18 Increase Workload on OOW002 OOW2 gets 12 cpus

OOW3 gets 2 cpus Only allocating 18 cpus instead of 24 cpus



OOW002 11 12 2200 3200

OOW003 2 2 200 200

56

Total CPU Allocation Unchanged at 18

Increase Workload on OOW003



OOW002 12 10 3200 2700

OOW003 2 8 200 1400


Program Agenda

Oracle Multitenant





1

2

3

4

5

57


Key Take Aways – Oracle Multitenant and MAA

• Multitenant is the ideal virtualization strategy to minimize CapEx and OpEx

• Oracle MAA database-optimized capabilities achieve more aggressive SLAs required by shared infrastructure – HA and data protection against infrastructure

failures (e.g. server, cluster, storage array, site) – Isolation between databases that share common

infrastructure in order to deliver reliable service

Oracle Confidential – Internal/Restricted/Highly Restricted 58

Second Generation Consolidation

Virtualize the Database


PDBn

PDB10

PDB8

PDB6

PDB3

PDB2

PDB11

PDB9

PDB7

PDB5

PDB3

PDB1

Oracle Home Container Database


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

Active Data Guard – Data Protection, DR – Query Offload

GoldenGate – Active-active replication – Heterogeneous

Active Replica

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

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

RAC – Scalability – Server HA

ASM – Local storage

protection

Production Site

Flashback – Human error

correction

Oracle Maximum Availability Architecture (MAA)


High Availability for Consolidated Environments

60

Protecting the basket… and the Eggs


Resources • MAA Best Practices for Database Consolidation

– http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdf

• Oracle MAA on the Oracle Technology Network – www.oracle.com/goto/maa

• Oracle Multitenant on the Oracle Technology Network – www.oracle.com/goto/multitenant

61


Key HA Sessions and Demos by Oracle Development Monday, 29 September, Moscone South

11:45 MAA with Oracle Multitenant – Seeing is Believing, 104 1:30 Oracle Database 12c HA for Consolidation and Cloud, 306 2:45 Zero Data Loss Recovery Appliance, New Era in Data Protection, 307 4:00 Oracle GoldenGate 12c for Oracle Database 12c, 305 5:15 Maximizing Oracle RAC Uptime, 103 Tuesday, 30 September, Moscone South 10:45 Active Data Guard and GoldenGate HA Best Practices, 308 12:00 Zero-Downtime Mantra for Applications with Oracle RAC, 309 3:45 Zero Data Loss Recovery Appliance Best Practices, 305 5:00 Oracle WebLogic Server 12c: Oracle Database Integration, 304 5:00 Geodistributed Oracle GoldenGate and Active Data Guard:

Global Data Services, 307

Wednesday, 1 October, Moscone South 10:15 Resource Manager Best Practices 11:30 RMAN Best Practices in Oracle Database 12c, 104 12:45 Active Data Guard: Best Practices and Deep Dive, 104 2:00 Expert High-Availability Best Practices for Oracle Exadata, 102 4:45 GoldenGate Performance and Tuning for Oracle, NORTH 130

Thursday, 2 October, Moscone South 9:30 Best Practices for Zero Downtime, 103 12:00 Data Protection,Recovery and HA for Private Cloud, 103 Demos – Moscone South

Oracle Maximum Availability Architecture, SLD-140 Oracle Active Data Guard, SLD-145 Global Data Services, SLD-144

Continuous Availability, SLD-125 RMAN, Database Backup Cloud Service, Flashback, SLD-141 Oracle Secure Backup, SLD-142 Oracle Real Application Clusters, SLD-128

oracle.com/goto/availability https://blogs.oracle.com/MAA @OracleMAA

Maximum Availability With Multi Tenant Database

Documents

Transcript of Maximum Availability With Multi Tenant Database