Multitenant MAA
Multitenant MAA
Multitenant MAA
November 2022
Program Agenda
1
Multitenant Overview and Benefits
2 Exadata and Resource Management Benefits
3 Choosing the Best Exadata Multitenant MAA Solution
to Meet SLAs
4 Exadata Multitenant MAA Reference Architectures and
Key Features
Complementary to VMs
Minimize OpEx
• Manage many databases as one (Less administration)
• One upgrade, one HA solution, one backup, possibly one DR solution (more on this later)
Enable higher consolidation densities
• Share resources: CPU, memory, background processes
Mission Critical Applications/databases may require more isolation
• Non-CDBs are supported up to 19c
• Avoiding oversubscribing PDBs to prioritize predictable performance, HA, and DR
• PDBs within the same CDB should have the same/similar SLAs and planned maintenance windows (e.g. DR
tests)
And you may need multiple CDBs!
• For multiple Oracle versions, e.g., 18c vs 19c
• For varying Oracle options, e.g., partitioning, RAC, Data Guard
• For different performance, HA & DR, security and consolidation density requirements
• For different planned maintenance window or DR testing requirements
Multitenant
databases, hosting Exadata Compute Node
Exadata Storage Cell
multiple pluggable
databases
CDB #1
PMEM/Flash
Standalone
(single tenant) CDB #2
Multiple databases,
databases, when sharing Exadata
needed storage
Hard Disks
Database
Noisy neighbors
• One database’s high loads should not disturb the others
• Data warehouses must co-exist with OLTP databases
Fair access to resources
• Databases need configurable, guaranteed access to CPU, memory, I/O, etc.
Options to capitalize on excess or idle resources
• Allow databases to “burst” into unused resources
• Or limit usage for “pay for performance” clouds or to ensure predictable performance
Dynamic resize of database resource allocations
• Change resource allocations without restarts
Choosing Exadata
Multitenant MAA
Architecture to Meet SLAs
4. Does the primary and standby resources have to be identical to preserve same application
performance after a role transition?
• Yes: Symmetric Standby with same resource allocation
• No: Asymmetric standby is allowed
5. What is the minimum isolation and distance for DR solution if required?
• Meters: Fault Domain isolated system resources and power but in same data center
• KMs: Availability Domain is different data center in the same region (e.g., < 25Kms)
• 100s to 1000s KMs: Region in different cities or countries
6. Can the application fail over to remote database and still meet performance requirements?
• Yes – implement transparent app failover following MAA best practices
• No – A separate app tier may be required for DR. For DR, a site failover may include app and
database failover
MAA Reference RTO for HA / RTO for DR / RPO for DR On-Premise Oracle Cloud
Architecture Downtime for Downtime for
Software DB Upgrades
Updates
Bronze MAA Hour(s) Hours < 15 or 30 mins* Yes Yes
Secs with ZDLRA*
Silver MAA Zero or Secs Hours < 15 or 30 mins* Yes – Yes- ExaDB, ExaCC, ADB
Secs with ZDLRA* Exadata, RAC
Gold MAA Zero or Secs < 2 mins Zero or secs Yes Yes – ExaDB
Secs with ZDLRA* RAC & ADG ExaCC, ADB-D
Platinum MAA Zero or Secs Zero or secs Zero or secs Yes Yes – ExaDB/ExaCC ***
RAC,
ADG,+GG
All RTO and RPO values are service level objectives that have been validated. To achieve these values specific MAA config and operational practices are in
place. Note all DR operations are fully automatic today. The RTO for DR calculation is based on after the failover is automatically or manually triggered.
* Based on archive backup frequency. For ADB, it’s < 15 mins. With ZDLRA, seconds. ZDLRA is available for On-premise and ExaCC
** Based on online redo log push
*** Data Guard Fast-Start Failover (FSFO) is manual in the cloud except for ADB-D which includes FSFO automation. Oracle GoldenGate setup is manual
16 Copyright © 2022, Oracle and/or its affiliates
Pluggable Database Placement Considerations
All application and user access to a PDB should utilize user-defined services
• Applications should never utilize default PDB services
Controlled PDB open on database startup with Oracle Clusterware
• Configure preferred and available RAC instances and assigned database role to route services
according for different outage cases
• Do NOT use AFTER STARTUP triggers or ALTER PLUGGABLE DATABASE.. SAVE STATE
Continuous availability
Data protection
Active replication
Production site Replicated site
Single
Dev, Test, Prod - Single Instance or Instance
Multitenant Database with Backups Database
Local Replicated
• Single Instance with Clusterware Backup Backups
Restart
• Advanced backup/restore with
RMAN Outage Matrix
• Optional ZDLRA with Unplanned Outage RTO / RPO Service Level Objectives (f1)
incremental forever and near
Recoverable node or instance failure Minutes to hour (f2)
zero RPO
• Storage redundancy and Disasters: corruptions and site failures Hours to days. RPO since last backup or
validation with ASM near zero with ZDLRA
Cloud
Storage
Day 2 Changes Day 1 State
Day N
2 State
Transactional
Block a
Remote
Changes
Replica
Virtual
Day N Changes
Full
Backup
Continuous
Queries & Transform
Update
Updates Updates
Tracking
Store
Additional Benefits of using DBMS_REDEFINITION Updates
• Fault Tolerant (resume at point of failure) and track changes to enable fast rollback to prior definition
• Entire redefinition process runs without acquiring Exclusive DDL lock
• Monitor reorganization using V$online_redef
Bronze +
Local Replicated
• Real Application Clustering (RAC) Backup Backups
• Application Continuity
• Sharding (Optional)
• Provides fault isolation,
scalability and geographical
Outage Matrix
distribution Unplanned Outage RTO/RPO Service Level Objectives(f1)
Recoverable node or instance failure Single digit seconds (f2)
Disasters: corruptions and site failures Hours to days. RPO since last backup or
near zero with ZDLRA
Checklist found in MAA OTN Planned Maintenance
https://www.oracle.com/a/tech/docs/application- Software/Hardware updates Zero (f2)
checklist-for-continuous-availability-for-maa.pdf
Major database upgrade Minutes to hour
f1: RPO=0 unless explicitly specified
f2: To achieve zero downtime or lowest impact, apply application checklist best
practices; Batch jobs should be deferred outside planned maintenance window.
28 Copyright © 2022, Oracle and/or its affiliates
Oracle Real Application Clusters (Oracle RAC)
Node Failure, Instance Failure, Rolling Maintenance
RAC Cluster
Single
CDB /
Shared
Storage
Inst2
Inst3
RAC Cluster
Single
CDB /
Shared
Storage
RAC Cluster
Single
CDB /
Shared
Storage
Inst3
Inst4
RAC Cluster
PDB1 PDB2 PDB3 PDB4 PDB5 PDB6 PDB7 PDB8 PDB9 PDB10 PDB11 PDB12
Inst1
P P P
Inst2
A M M
Inst3
M A M
Inst4
M M A
RAC Cluster
1 2
MAA Reference RTO for HA / RTO for DR / RPO for DR On-Premise Oracle Cloud
Architecture Downtime for Downtime for
Software Updates DB Upgrades
Bronze MAA Hour(s) Hours < 15 or 30 mins* Yes Yes
Secs with ZDLRA*
Silver MAA Zero or Secs Hours < 15 or 30 mins* Yes – Yes- ExaDB, ExaCC, ADB
Secs with ZDLRA* Exadata, RAC
“Aurous” Option Zero or Secs < 10 mins < 5 mins ** No – refreshable Yes – ADB-S only
clones can help
Gold MAA Zero or Secs < 2 mins Zero or secs Yes Yes – ExaDB, ExaCC, ADB-D
Secs with ZDLRA* ***
Platinum MAA Zero or Secs Zero or secs Zero or secs Yes Yes – ExaDB/ExaCC ***
All RTO and RPO values are service level objectives that have been validated. To achieve these values specific MAA config and operational practices are in
place. Note all DR operations are fully automatic today. The RTO for DR calculation is based on after the failover is automatically or manually triggered.
* Based on archive backup frequency. For ADB-D, it’s < 15 mins. With ZDLRA, seconds. ZDLRA is available for On-premise and ExaCC
** Based on online redo log push
*** Limitations described later but setup is mostly manual
39 Copyright © 2022, Oracle and/or its affiliates
The “Aurous” MAA Strategy
Replication
Server2 2. create pluggable database Red
from Red@CDB1_Link
refresh mode every 2 minutes;
3. create pluggable database Gold;
CDB2 5. create pluggable database Grey;
Server1
CDB1
Replication
Replication
Server2
Server1
CDB1
Replication
Replication
Determining factors:
• Rate of redo generation at source
• Frequency of refresh of replica
Worst case: Failure of source just prior to next refresh
Best practices:
• Relatively high frequency of refresh (minutes rather than hours)
• Thorough testing with realistic transaction volumes
Mission Critical
Silver +
• Active Data Guard
Local Local Primary Remote Local
• Comprehensive Data Protection backup Standby RAC RAC Standby RAC backup
MAA Architecture:
• At least one standby required
across AD or region.
Outage Matrix
Unplanned Outage RTO/RPO Service Level Objectives (f1)
• Primary in one data center(or AD)
replicated to a Standby in another Recoverable node or instance failure Single digit seconds (f2)
data center
Disasters: corruptions and site failures Seconds to 2 minutes. RPO zero or
• Active Data Guard Fast-Start seconds
Failover (FSFO)
Planned Maintenance
• Local backups on both primary and
standby Software/Hardware updates Zero (f2)
Primary Secondary
Site Site
• Basic DR (included with DB EE)
- License primary and secondary sites
• Active-passive
- Standby is used only for failovers
Sync or Async Replication
via in-memory Redo
• Automatic failover to Standby site
https://www.oracle.com/database/technologies/high-availability/dataguard-activedataguard-demos.html
48 Copyright © 2022, Oracle and/or its affiliates
Oracle Active Data Guard (ADG)
Primary Secondary
Site Site • Advanced Disaster Recovery
• Active-active*
- Queries, reports, backups
DML Redirection - Occasional updates (19c)
Zero data loss at
Any distance
- Assurance of knowing system is operational
Rolling Database
• Automatic block repair
Upgrades
https://www.oracle.com/database/technologies/high-availability/dataguard-activedataguard-demos.html
49 Copyright © 2022, Oracle and/or its affiliates
Gold MAA Strategy with Multitenant
SYNC ASYNC
Limited distance Any distance
Redo compressed over WAN
3
1 2
7000
6000
Standby 5000
Apply
Rate 4000 5000
MB/sec
3000
2000 2752
1000 1400
1480
700 740
190 380
0
1 Instance 2 Instances 4 Instances 8 Instances
OLTP Batch
54 Copyright © 2022, Oracle and/or its affiliates
Database Rolling Upgrade to 19c
Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING
Standby
CDB 2
Read-Write
PDB2
CDB 2
Read-Write
CRM HR
Oracle Cloud
Using PDB Relocation to Move a Single PDB to Another CDB Without Upgrade (Doc ID 2771737.1)
Using PDB Relocation to Upgrade an Individual PDB Document 2771716.1.
On-Premises
64 Copyright © 2022, Oracle and/or its affiliates
Multitenant “Gold” MAA Strategy
Gold + GG
• GoldenGate Active/Active Replication
Replication
Local Local
• Edition-based Redefinition
backup Standby RAC Primary RAC Primary RAC Standby RAC backup
(Alternative)
MAA Architecture:
• Each GoldenGate “primary” replica
protected by Exadata, RAC and
Outage Matrix
Active Data Guard Unplanned Outage RTO/RPO Service Level Objectives
• Primary in one data center (or AD) (f1)
replicated to another Primary in Recoverable node or instance failure Zero or single-digit seconds (f2/f3)
remote data center (or AD)
• Oracle GG & Edition-based Disasters including corruptions and site failures Zero (f3)
Redefinition for zero downtime
application upgrade Planned Maintenance
• Local backups on both sites Most common software/hardware updates Zero (f2)
• Achieve zero downtime through Major database upgrade, application upgrade Zero (f3)
custom failover to GG replica
f1: RPO=0 unless explicitly specified
f2: To achieve zero downtime or lowest impact, apply application checklist best practices
66 Copyright © 2022, Oracle and/or its affiliates f3: Application failover is custom or with Global Data Services
External Resources