maximum availability with multi tenant database
Post on 12-Jan-2016
34 Views
Preview:
DESCRIPTION
TRANSCRIPT
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. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Evolution in Consolidation Strategies for Oracle Database
3
DB7
Oracle home Guest O.S.
DB4
Oracle home Guest O.S.
DB3
Oracle home Guest O.S.
DB1
Oracle home Guest O.S.
DB8
Oracle home Guest O.S.
DB6
Oracle home Guest O.S.
DB4
Oracle home Guest O.S.
DB2
Oracle home Guest O.S.
Host Operating System
First Generation
Virtualize the Machine Second Generation
Virtualize the Database
Host Operating System
PDBn
PDB10
PDB8
PDB6
PDB3
PDB2
PDB11
PDB9
PDB7
PDB5
PDB3
PDB1
Oracle Home Container Database
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
HA Implications of Consolidation onto Shared Infrastructure
6
PDB2
PDBn
PDB3 PDB1
Multitenant Container Database
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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)
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
MAA Benefits for Oracle Multitenant
Benefit Capability Enabled
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
MAA Benefits for Oracle Multitenant
Benefit Capability Enabled
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
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
11
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
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
23
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
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
35
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Demonstration Overview
• 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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Demonstration Overview
• 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
PDB Average CPU Before After
Average TPS Before After
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
PDB Average CPU Before After
Average TPS Before After
OOW002 11 12 2200 3200
OOW003 2 2 200 200
56
Total CPU Allocation Unchanged at 18
Increase Workload on OOW003
PDB Average CPU Before After
Average TPS Before After
OOW002 12 10 3200 2700
OOW003 2 8 200 1400
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
57
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Host Operating System
PDBn
PDB10
PDB8
PDB6
PDB3
PDB2
PDB11
PDB9
PDB7
PDB5
PDB3
PDB1
Oracle Home Container Database
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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)
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
High Availability for Consolidated Environments
60
Protecting the basket… and the Eggs
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
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
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 63
top related