Multitenant MAA

Download as pdf or txt
Download as pdf or txt
You are on page 1of 64

Multitenant MAA Solutions

Blueprints for reduced planned and unplanned downtime for


the Multitenant Oracle Database Architecture

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

2 Copyright © 2022, Oracle and/or its affiliates


Maximum Availability Architecture (MAA)

Multitenant Overview and


Benefits

3 Copyright © 2022, Oracle and/or its affiliates


Advantages of Multitenant Architecture
Isolation and agility with economies of scale

Self-contained PDB for each application


AP
• Applications run unchanged
GL OE
• Rapid provisioning (via clones)
• Portability (via pluggability)

Common operations performed at CDB level


• Manage many as one (upgrade, HA, backup)
• Granular control when appropriate

Shared memory and background processes


• More applications per server

Complementary to VMs

4 Copyright © 2022, Oracle and/or its affiliates


Oracle Multitenant Features

Rapid cloning and Manage many Improve agility Enhance Integration


provisioning as one for development security with Oracle RAC
• Local clones and • Database teams • Separation of duties • High availability
remote clones consolidation • Pre-configured • Data security • Scalability
• Snapshot clones • Improve service level
• Resource isolation • Flexibility
productivity agreement
• Refreshable PDBs
• Maintain granular • Compatibility
control • Interface

5 Copyright © 2022, Oracle and/or its affiliates


Exadata and Resource Management

• Exadata is best database consolidation platform.


• Consolidate databases with similar SLAs, planned maintenance windows and DR requirements
within the same container (CDB).
• Resource Management manages and isolates resources for applications.
• Critical Success Factors for Best Oracle Database Consolidation

6 Copyright © 2022, Oracle and/or its affiliates


Consolidation Architecture Best Practices
Multitenant reduce overall costs

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

7 Copyright © 2022, Oracle and/or its affiliates


Best Practice Consolidation Architecture

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

Best practice and most prevalent consolidation architecture:


Multiple multitenant databases on Exadata!
8 Copyright © 2022, Oracle and/or its affiliates
Best Practice Consolidation Architecture
Why Exadata?

Smart storage offloads database servers


• Smart scan, columnar features, storage indexes decrease the server and network load
• Improves consolidation density!
Built-in consolidation support
• Network prioritization for OLTP
• Resource management of PMEM and flash cache space, flash I/Os, disk I/Os
• Enables consolidation of mixed workloads
• Enables consolidation of production and dev/test databases
• Not available from any other storage vendor!

9 Copyright © 2022, Oracle and/or its affiliates


Resource Management
Consolidation Goals

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

10 Copyright © 2022, Oracle and/or its affiliates


Resource Management
Which Resources?

Exadata Compute Node


For PDBs: Exadata Storage Cell
• CPU
• SGA
• PGA CDB #1
• Sessions For Exadata cells
PMEM/Flash
• Parallel servers PMEM & flash space
Flash bandwidth
CDB #2 Disk bandwidth
For Databases: Storage network
• CPU
• SGA Hard Disks
• PGA
• RAC network
Database

Resource Manager controls access to all critical resources.


11 Copyright © 2022, Oracle and/or its affiliates
Maximum Availability Architecture (MAA)

Choosing Exadata
Multitenant MAA
Architecture to Meet SLAs

12 Copyright © 2022, Oracle and/or its affiliates


Multitenant MAA Considerations & Solution Flow

1. Key Questions to 2. Understands MAA


determine SLAs solution offerings that
meets SLAs

3. Customer picks best 4. Implements Best


reference architecture in Practices
the cloud or on-premise

13 Copyright © 2022, Oracle and/or its affiliates


Key Questions

1. What’s the maximum RTO SLA for local failures?


• Pick one: Near Zero or Secs (HA) or hour(s)
• If “hour(s)”, skip all questions and choose Bronze MAA. Otherwise, minimally Silver MAA.
2. What’s the maximum RTO for disasters?
• Pick one: Near Zero, < 2 mins, < 15 mins, Hours
• Hours: Bronze or Silver MAA
• Less than 15 mins, Gold MAA or “Aurous” Option strategy (introduced later in deck)
• Less than 2 mins, Gold MAA option strategy (possible with restricted number of databases and services)
• Near Zero: Platinum MAA
3. What’s the maximum data loss tolerated (RPO SLA) in case of disaster?
• Pick one: Zero, Seconds, < 5 minutes, < 30 minutes
• Less than 30 minutes: Available in all MAA tiers
• Less than 5 minutes: Gold MAA or “Aurous” Option strategy (introduced later in deck)
• Near Zero or Seconds: Gold MAA with async transport with strategy
• Zero: Gold or Platinum MAA with sync transport

14 Copyright © 2022, Oracle and/or its affiliates


Key Questions

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

15 Copyright © 2022, Oracle and/or its affiliates


Picking MAA Reference Architecture

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

• Container should not mix databases with different SLAs


• Test/Dev/Production that needs HA only should be Silver Container
• Production Databases that need HA and DR should be in Gold Container with ADG
• Production Databases that need HA, DR and logical replication should be in Platinum Container with ADG &
GG
• All pluggable databases within a container should have
• Similar planned maintenance windows (relevant for all tiers)
• Same database version and upgrade schedules (relevant for all tiers)
• Same DR test requirements (relevant for Gold and Platinum)
• Same DR target destination requirements (relevant for Gold and Platinum)
• To reduce DR failover times
• Minimize number of pluggable databases within a container for Gold/Platinum (<25 PDBs)
• Minimize number of Clusterware managed services within a cluster (< 250 services/CDB)
• Ensure sufficient system resources and symmetric standby
• Test and tune using MAA practices

17 Copyright © 2022, Oracle and/or its affiliates


Pluggable Database Placement Considerations
PDB Open on Database Startup

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

18 Copyright © 2022, Oracle and/or its affiliates


Maximum Availability Architecture (MAA)

MAA Multitenant: Blueprints


for Oracle Database HA & DR

19 Copyright © 2022, Oracle and/or its affiliates


Oracle Maximum Availability Architecture (MAA)
Standardized Reference Architectures for Never-Down Deployments

Continuous availability

Customer insights and expert recommendations


Platinum

Application Online Edition-based


Continuity Redefinition Redefinition

Data protection

Reference 24/7 HA features,


architectures configuration
Replication and operational Flashback RMAN + ZDLRA
practices
Gold

Active replication
Production site Replicated site

Active Data Guard GoldenGate


Deployment choices
Silver

Scale out & Lifecycle

Generic Systems Engineered Systems BaseDB, ExaDB/ExaCC Autonomous DB


Bronze

Zero Downtime Migration (ZDM) RAC FPP Sharding

20 Copyright © 2022, Oracle and/or its affiliates.


BRONZE Primary Availability Domain Secondary Availability Domain

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

• Multitenant Database/Resource Planned Maintenance


Management with PDB features Software/hardware updates Minutes to hour (f2)
• Online Maintenance Major database upgrade Minutes to hour
• Some corruption protection f1 : RPO=0 unless explicitly specified
f2 : Exadata systems has RAC but Bronze Exadata configuration with Single Instance database
• Flashback technologies running with Oracle Clusterware has highest consolidation density to reduce costs

21 Copyright © 2022, Oracle and/or its affiliates.


Oracle Clusterware for Automatic Restart

1. Oracle Clusterware is available for all Oracle Databases


2. Enables HA capabilities and resource management:
• Automatic Restart of database instances, listeners and other resources
• Fleet patching
• Service management including restarting service after failure
• Automatic Storage Management (ASM) for HA, data protection and ease of use

• Trade off: additional software maintenance for Grid Infrastructure

22 Copyright © 2022, Oracle and/or its affiliates


Oracle Recovery Manager - RMAN
Database Integrated Backup and Recovery

• Unique knowledge of database file


formats and recovery procedures
• Oracle block validation
• Online block-level recovery
• Native encryption, compression
• Table/partition-level recovery
• Oracle Multitenant support
• Tape and cloud backups
• Unified Management

23 Copyright © 2022, Oracle and/or its affiliates


Recovery Appliance Recommended EM Real-Time
Protection Status
& Space Monitoring

Databases Day 1 Full

Cloud
Storage
Day 2 Changes Day 1 State
Day N
2 State
Transactional
Block a
Remote
Changes
Replica
Virtual
Day N Changes
Full
Backup

Oracle DB 12c-21c No More Full Backups, Tape


on Any Platform Incremental Forever

End-to-End Oracle Recovery Validation


Near Zero Data Loss for DR

24 Copyright © 2022, Oracle and/or its affiliates


Database and Exadata Health Checks

Assessment Report Findings & Recommendations MAA Score Card


• Health Score, Summary, • How to Solve the problem? • MAA architectural readiness
Findings and configuration practices

Note: Automated Orachk/Exachk Healthcheck MOS 107954.1 updated frequently


25 Copyright © 2022, Oracle and/or its affiliates
Online Operations
Online Redefinition Improvements

DBMS_REDEFINITION allows you to reorganize and redefine tables online


• Add/drop/rename/reorder columns
Source Result
• Switch physical storage structures Table Copy
Transform
Table
• Reorganize & transform data while online Table

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

26 Copyright © 2022, Oracle and/or its affiliates


Flashback Technologies
Rewind Button for Oracle Databases

• Fast point-in-time recovery (PITR)


without expensive restore operation
• Error investigation
• View data as of previous point in time
• Error correction
• Back-out a transaction
• Incorrect table updates
• Rewind the entire database

27 Copyright © 2022, Oracle and/or its affiliates


SILVER Primary Availability Domain Secondary Availability Domain
RAC
Prod/Departmental Database

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

• Utilizes two or more instances of an


Application
Tier Oracle Database concurrently
• Very Scalable
• All instances active; Add capacity online; Ideal for
database consolidation
• Highly Available
Database • Auto-failover of services to an already running
Services Database instance
Tier • Outage is transparent to user, in-flight
transactions succeed
Primary Database • Zero downtime rolling maintenance

29 Copyright © 2022, Oracle and/or its affiliates


Multitenant and RAC: Affinity

PDB1 PDB2 PDB3 PDB4 PDB5 PDB6


• Single CDB
Inst1
• Two-node cluster
• Single instance per node
• PDB’s affinity to a node
defined by starting its services
Inst2 there
• Present in “mounted” state
in other nodes

RAC Cluster

Single
CDB /
Shared
Storage

30 Copyright © 2022, Oracle and/or its affiliates


Multitenant and RAC: Scalability and Agility

PDB1 PDB2 PDB3 PDB4 PDB5 PDB6


• Expand cluster
Inst1
• Redistribute PDBs
• Use Srvctl

Inst2

Inst3

RAC Cluster

Single
CDB /
Shared
Storage

31 Copyright © 2022, Oracle and/or its affiliates


Multitenant and RAC: Scalability and Agility

PDB1 PDB2 PDB3 PDB4 PDB5 PDB6 PDB7 PDB8


• Single CDB
Inst1
• Single instance per node
• PDBs may be configured with
“singleton” affinity to
a specific node
Inst2 • Present in “mounted” state
in other nodes
• PDBs may be open in multiple
nodes
Inst3

RAC Cluster

Single
CDB /
Shared
Storage

32 Copyright © 2022, Oracle and/or its affiliates


Singleton Affinity of PDB to Instance in RAC Cluster

PDB1 PDB2 PDB3 PDB4 PDB5 PDB6 PDB7 PDB8


• Per-PDB lock domain
provides strong isolation
Inst1
• Cache Fusion following
instance failure can ignore
PDBs not open in affected
nodes
Inst2

Inst3

Inst4

RAC Cluster

33 Copyright © 2022, Oracle and/or its affiliates


Multitenant and RAC: Availability

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

34 Copyright © 2022, Oracle and/or its affiliates


Transparent Application Continuity (TAC)
Application does not see errors during outages

• Uses Application Continuity and


Oracle Real Application Clusters
Request • Transparently tracks and records session
information in case there is a failure
• Built inside of the database, so it works
without any application changes
• Rebuilds session state and replays in-flight
Transparent transactions upon unplanned failure
Application
Continuity • Planned maintenance can be handled by
TAC to drain sessions from one or more
nodes
• Adapts as applications change:
protected for the future
Errors/Timeouts hidden

35 Copyright © 2022, Oracle and/or its affiliates


Planned Maintenance

Planned Maintenance (without the Outages!):


1. Database Service is relocated or stopped
2. Service starts on another RAC instance 5
3. Sessions connected to the service are drained
4. New sessions connect to Service on another instance
5. Results from Database Request returned to user 3 4
6. Maintenance activities can start on first node (rolling)
1 2

36 Copyright © 2022, Oracle and/or its affiliates RAC Cluster


Unplanned Outages, without Impact
Outage or Interruption at Database:
1. Database Request interrupted by an Outage or timeout
2. Session reconnects to the RAC Cluster and
4 3. Database Request replays automatically
4. Result from Database Request returned to user

1 2

37 Copyright © 2022, Oracle and/or its affiliates


Introducing the “Aurous” MAA Option
Multitenant Architecture-based Disaster Recovery

Flexible PDB Placement using PDB refreshable clones


• Great HA and PDB flexibility. Good data protection & DR. Automation built-in to ADB-S
• CDBs can host any PDB with varying SLAs
• Non-Critical, Business Critical and Mission Critical PDBs can reside in the same CDB
• Business critical PDBs can fail over to another RAC instance
• Mission critical PDBs can fail over to remote PDB in another CDB
• Some advanced features not available such as RO standby, automatic DR failover for site failure,
fast reinstate after role transition
• Capability is very innovating
• RTO=secs for HA and RTO < 10 min for DR (not automatic)
• RPO for DR < 5 min

38 Copyright © 2022, Oracle and/or its affiliates


Picking MAA Reference Architecture

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

• CDB has mix of primary & DR copy PDBs


• Individual PDBs can transition roles
independently
• Standby PDBs are mounted

40 Copyright © 2022, Oracle and/or its affiliates


Refreshable PDBs as Replicas
Per-PDB replica with only two CDBs to manage!

Server1 1. create pluggable database Red;


4. create pluggable database Brown;
6. create pluggable database Grey
from Grey@CDB2_Link
CDB1 refresh mode every 2 minutes;
Replication

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;

41 Copyright © 2022, Oracle and/or its affiliates


Refreshable PDB Switchover
Planned switchover

Server1

CDB1
Replication

Replication
Server2

1. alter pluggable database Grey


refresh mode every 2 minutes
CDB2 from Grey@dblink switchover;

42 Copyright © 2022, Oracle and/or its affiliates


Refreshable PDB Switchover
Unplanned switchover

Server1

CDB1

Replication
Replication

Server2 1. alter pluggable database Grey


refresh;
2. alter pluggable database Grey
refresh mode none;
3. alter pluggable database Grey
CDB2 open read write;

43 Copyright © 2022, Oracle and/or its affiliates


Recovery Time Objectives (RTOs)
How long does it take to recover?

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

44 Copyright © 2022, Oracle and/or its affiliates


Multitenant “Aurous” MAA Strategy

Unplanned Outages Key Features for Solution RTO RPO


Recoverable node or instance failure Real Application Cluster (RAC) Secs Zero
Application Continuity (AC/TAC)
Disasters: corruptions and site failures Many Refreshable PDB Switchover Not automatic Since last
operations (target < 15 refresh (min
PDB unrecoverable failure or “sick” PDB Refreshable PDB Switchover mins after 15 mins)
manual ops)

Planned Maintenance Solution RTO


Software and hardware updates RAC, AC or TAC Zero
Major database upgrade (for all PDBs) CDB offline upgrade 60+ Minutes
Migration to remote CDB PDB Relocate Mins
Migration to remote CDB (logical migration) Data Pump and GoldenGate or ZDM Potentially Zero
Migration plus upgrade (single PDB) PDB Relocate + Upgrade Mins
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 (Doc ID 2771716.1)
ZDM stands for Zero Downtime Migration. Refer to www.oracle.com/goto/zdm
45 Copyright © 2022, Oracle and/or its affiliates
GOLD Primary Region
AD2
DG FSFO
AD1
Secondary Region

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)

Major database upgrade Less than 30 seconds


f1: RPO=0 unless explicitly specified
f2: To achieve zero downtime or lowest impact, apply application checklist best practices; Batch jobs
46 Copyright © 2022, Oracle and/or its affiliates
should be deferred outside planned maintenance window.
Storage Remote Mirroring Architecture

Generic - Must Transmit Writes to All Files


…. INCLUDING CORRUPTED BLOCKS OR BAD DATA
Primary Database Mirrored Volumes

Oracle Instance (in memory)


• Zero Oracle validation
• 7x network volume
• 27x network i/o
SYNC or ASYNC
block replication

47 Copyright © 2022, Oracle and/or its affiliates


Oracle Data Guard (DG)

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

• Zero / near-zero data loss

• Continuous data validation


Data Guard Broker
(Enterprise Manager Cloud Control or DGMGRL)
• Simple migrations and upgrades

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

Automatic Block Repair • Application Continuity

• Zero data loss across any distance


Data Guard Broker
(Enterprise Manager Cloud Control or DGMGRL)
Offload read mostly Offload fast
• Many other features
workload to open incremental
standby database backups

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

• Active Data Guard of the CDB with automatic failover


• Automatic smart failover when primary is inaccessible
• Auto-block repair, offload read and reporting and backups
• PDB failover and relocate operations

50 Copyright © 2022, Oracle and/or its affiliates


Active Data Guard Far Sync
Zero Data Loss Protection at Any Distance

SYNC ASYNC
Limited distance Any distance
Redo compressed over WAN

Far Sync Instance


Primary Database • Oracle control file and log files Active Standby Database
• Production copy • No database files • Zero data loss failover target
• No media recovery • Database open read-only
• Offload transport compression and/or • Continuous Oracle validation
encryption • Manual or automatic failover

51 Copyright © 2022, Oracle and/or its affiliates


Unplanned Outages, without Impact expanded to the Standby
Outage or Interruption at Database:
1. Database Request interrupted by an Outage or timeout
2. Session reconnects to the RAC Cluster (or Standby) and
4 3. Database Request replays automatically
4. Result from Database Request returned to user

3
1 2

Primary Active Data Guard Standby


52 Copyright © 2022, Oracle and/or its affiliates
Extend Footprint of ADG Applications
Support for DML Re-direction

• DML Re-direction is automatically performed from


an Active Data Guard standby to the primary (ACID uncompromised)
• New parameter ADG_REDIRECT_DML controls DML Redirection
• New ADG_REDIRECT_DML and ADG_REDIRECT_PLSQL

• “Read-Mostly, Occasional Updates” applications


DATA IS VISIBLE
TO CLIENT

supported for Oracle Database 19c DML

DML IS REDIRECTED TO PRIMARY

DML IS APPLIED TO PRIMARY

DATA CHANGE IS STREAMED TO PRIMARY

PRIMARY ACTIVE STANDBY

53 Copyright © 2022, Oracle and/or its affiliates


Multi-Instance Redo Apply Performance
Lower Latency Active Data Guard Standby Databases

• Utilizes all RAC nodes on the Standby database to parallelize recovery


• OLTP workloads on Exadata show great scalability

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

Database Rolling Upgrade with DBMS_ROLLING


• Pre-checks and early problem detection
• Fault tolerant, resumable and rollback capabilities
• Three Role Transition Steps: Start, Switchover, Finish
• Potential Maintenance Window: Hours
• Potential Database and Application Downtime: Seconds

Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING

55 Copyright © 2022, Oracle and/or its affiliates


Multitenant Replication Capabilities

Manage many as one with Data Guard


Server1 (Standbys • When creating new local PDBs,
= None)
the new PDBs are automatically
PDB1 PDB2 PDB3 PDB4 replicated and represented on the
standby.
Primary
Data Guard Replication

• What happens when cloning a


Server2 remote PDB or plugging in new
PDBs?
PDB1’ PDB2’ PDB3’

Standby

56 Copyright © 2022, Oracle and/or its affiliates


What if only one PDB is down or needs to be relocated?

• PDB failover is possible by migrating to a new CDB.


• This should be extremely rare case. With proper planning, all database (PDBs) in the same CDB
should have same HA and DR requirements, planned maintenance schedules, DR testing schedules
and data center requirements
• A single failed PDB that is not restartable is extremely rare
• PDB relocate can be used move a PDB to another CDB (same release or different release)

61 Copyright © 2022, Oracle and/or its affiliates


PDB Failover: Normal Runtime

PDB1 PDB2 PDB3 PDB1 PDB2 PDB3


CDB 1 CDB 1
Read-Write Standby
Data Guard Read- Only

CDB 2
Read-Write

62 Copyright © 2022, Oracle and/or its affiliates


PDB Failover after PDB 2 Outage
Migrate PDB2 from CDB1 standby to empty CDB2 and failover application connections

PDB1 PDB2 PDB3 PDB1 PDB2 PDB3


CDB 1 CDB 1
Read-Write Standby
Data Guard Read- Only

PDB2
CDB 2
Read-Write

63 Copyright © 2022, Oracle and/or its affiliates


Online PDB Relocation

CRM HR

Online PDB Relocation


• Relocate with minimal downtime

Oracle Cloud

Pricing Retail CRM

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

Unplanned Outages Key Features for Solution RTO RPO


Recoverable node or instance failure Real Application Cluster (RAC) Secs Zero
Application Continuity (AC/TAC)
Disasters: corruptions and site failures Active Data Guard Fast-Start < 2 mins Zero or Secs
Failover
PDB unrecoverable failure or “sick” PDB PDB Failover (unplug/plug) < 2 mins Zero or Secs
or “PDB DR test” Another target CDB on the same
cluster required (MOS 2088201.1)

Planned Maintenance Solution RTO


Software and hardware updates RAC, AC or TAC Zero
Major database upgrade Active Data Guard DBMS_ROLLING Secs
PDB “DR Test” / PDB Switchover Similar to MOS 2088201.1 Mins
Migration to remote CDB PDB Relocate Mins
Migration to remote CDB (logical migration) Data Pump and GoldenGate or ZDM Potentially Zero
Migration plus upgrade PDB Relocate + Upgrade Mins
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 (Doc ID 2771716.1)
65 Copyright © 2022, Oracle and/or its affiliates ZDM stands for Zero Downtime Migration. Refer to www.oracle.com/goto/zdm
PLATINUM Primary Region Secondary Region
AD2 AD1 AD1 AD2
Extreme Critical

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

Maximum Availability Architecture


• Platinum MAA details:
• Oracle Maximum Availability Architecture (MAA) - Platinum Tier
• MAA Home:
• http://oracle.com/goto/maa
• On-Premise MAA:
• https://www.oracle.com/database/technologies/high-availability/oracle-database-maa-best-
practices.html
• Exadata MAA:
• https://www.oracle.com/database/technologies/high-availability/exadata-maa-best-
practices.html
• Cloud MAA:
• https://www.oracle.com/database/technologies/high-availability/oracle-cloud-maa.html

67 Copyright © 2022, Oracle and/or its affiliates

You might also like