Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Multitenant MAA SolutionsBlueprints for reduced planned and unplanned downtime for the Multitenant Oracle Database Architecture (includes the “Aurous” Option)
July, 2020
Safe harbor statement
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation.
2 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Program Agenda
Multitenant Overview and Benefits
Exadata and Resource Management Benefits
Choosing the Best Exadata Multitenant MAA Solution to Meet SLAs
Exadata Multitenant MAA Reference Architectures and Key Features
1
2
3
3 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
4
Maximum Availability Architecture (MAA)
Multitenant Overview and Benefits
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public4
Multitenant ArchitectureIsolation and agility with economies of scale
GL OE
APSelf-contained PDB for each application• Applications run unchanged• Rapid provisioning (via clones)• Portability (via pluggability)
Common operations performed at CDB level• Manage many as one
(patching, backups, HA, upgrades)• Granular control when appropriate
Shared memory and background processes• More applications per server
Complementary to VMs
5 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Multitenant Key Benefits
6
Minimize CapEx • More applications and databases per server
Minimize OpEx• Manage many as one (e.g patching,
upgrade, backup/restore, HA and DR )• Standardized procedures & service levels• Enable self-service provisioning
Maximize Agility• Snapshot cloning for development &
testing• Portability through “pluggability” • Scalability with RAC
Easy • To Adopt: Applications run unchanged• To Use: Interface is SQL
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Exadata and Resource Management• Exadata is best database consolidation platform. • Resource Management manages and isolates resources for applications. • Critical Success Factors for Best Oracle Database Consolidation
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public7
Best Practice Consolidation Architecture
8
Exadata Storage Cell
Hard Disks
CDB #2
Exadata Compute Node
PMEM/Flash
CDB #1
Database
Multiple databases, sharing Exadata
storage
Multitenant databases, hosting multiple pluggable
databases
Standalone (single tenant)
databases, when needed
Best practice and most prevalent consolidation architecture:Multiple multitenant databases on Exadata!
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Best Practice Consolidation ArchitectureMultitenant 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 is supported up to 19c• CDBs with single PDB or less PDBs and more headroom for critical databases
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
9 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Best Practice Consolidation ArchitectureWhy 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!
10 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Resource ManagementConsolidation 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
11 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Resource ManagementWhich Resources?
12
Exadata Storage Cell
Hard Disks
CDB #2
Exadata Compute Node
CDB #1
Database
For Exadata cellsPMEM & flash spaceFlash bandwidthDisk bandwidthStorage networkFor Databases
CPUSGAPGARAC network
For PDBsCPUSGAPGASessionsParallel servers
Resource Manager controls access to all critical resources.
PMEM/Flash
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Choosing Exadata Multitenant MAA Architecture to Meet SLAs
13 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Multitenant MAA Considerations & Solution Flow
3. Customer picks best reference architecture in the cloud or on-premise
2. Understands MAA solution offerings that meets SLAs
4. Implements Best Practices
1. Key Questions to determine SLAs
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public14
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 (introduced later in deck)• Less than 2 mins, Gold MAA • 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 (introduced later in deck)• Near Zero or Seconds: Gold MAA with async transport with strategy • Zero: Gold MAA or Platinum MAA with sync transport
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public15
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’s 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 with application continuity • No – A separate app tier may be required for DR that is co-located in the same data center or
region as the target production database. For DR, a site failover may include application and database failover
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public16
Picking MAA Reference Architecture
MAA Reference Architecture
RTO for HA /Downtime for Software Updates
RTO for DR /Downtime for DB Upgrades
RPO for DR On-Premise Oracle Cloud
Bronze MAA Hour(s) Hours < 15 or 30 mins*Secs with ZDLRA*
Yes Yes
Silver MAA Zero or Secs Hours < 15 or 30 mins*Secs with ZDLRA*
Yes –Exadata, RAC
Yes- ExaCS/ExaCC, ADB
Gold MAA Zero or Secs < 2 mins Zero or secs Yes Yes – ExaCS **
Future – ADB, ExaCC
Platinum MAA Zero or Secs Zero or secs Zero or secs Yes Yes – ExaCS/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. Not 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 log backup and refresh frequency. With ZDLRA, seconds. ZDLRA is available for On-premise and ExaCC ** Limitations described later but setup is mostly manual
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public17
Maximum Availability Architecture (MAA)
MAA Blueprint for Oracle On-Premise
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public18
Oracle Maximum Availability Architecture (MAA)
Reference Architectures
Deployment Choices
HA Features,Configurations &
OperationalPractices
Customer Insights & Expert
Recommendations
Production Site Replicated Site
Platinum
Gold
Silver
Bronze
Replication
Data Protection
Flashback RMAN + ZDLRA
Continuous Availability
Application Continuity
Global Data Services
Active Replication
Active Data Guard GoldenGate
Generic Systems
Engineered Systems
DBCSExaCS/ExaCC
Autonomous DB
Scale Out
RAC ShardingASM
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public19
Outage Matrix
SingleInstance Database
Primary Availability Domain Secondary Availability Domain
Local Backup
Replicated Backups
Dev, Test, Prod - Single Instance or Multitenant Database with Backups
• Single Instance with ClusterwareRestart
• Advanced backup/restore with RMAN
• Optional ZDLRA with incremental forever and near zero RPO
• Storage redundancy and validation with ASM
• Multitenant Database/Resource Management with PDB features
• Online Maintenance
• Some corruption protection
• Flashback technologies
BRONZE
Unplanned Outage RTO / RPO Service Level Objectives (f1)
Recoverable node or instance failure Minutes to Hour (f2)
Disasters: corruptions and site failures Hours to days. RPO since last backup or near zero with ZDLRA
Planned Maintenance
Software/hardware updates Minutes (f2)
Major database upgrade Minutes to hour
f1 : RPO=0 unless explicitly specifiedf2 : Exadata systems has RAC but Bronze Exadata configuration with Single Instance database running with Oracle Clusterware has highest consolidation density to reduce costs
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public20
Multitenant ArchitectureIsolation and agility with economies of scale
GL OE
APSelf-contained PDB for each application• Applications run unchanged• Rapid provisioning (via clones)• Portability (via pluggability)
Common operations performed at CDB level• Manage many as one
(patching, upgrade, HA, backup)• Granular control when appropriate
Shared memory and background processes• More applications per server
Complementary to VMs
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public21
Best Practice Consolidation Architecture
Exadata Storage Cell
Hard Disks
CDB #2
Exadata Compute Node
PMEM/Flash
CDB #1
Multiple databases, sharing Exadata
storage
Multitenant container databases, hosting multiple pluggable
databases
Standalone (single tenant)
databases, when needed
Best practice and most prevalent consolidation architecture:Multiple multitenant databases on Exadata!
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public22
CDB #3
Oracle Clusterware for Automatic Restart
23
1. Oracle Clusterware is available for all Oracle Databases2. 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
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Oracle Recovery Manager - RMANDatabase Integrated Backup and Recovery
24
RMAN
Data FilesFast Recovery
Area (FRA) Cloud
Tape
Disk Tape
• Unique knowledge of database file formats and recovery procedures
Oracle block validationOnline block-level recoveryNative encryption, compressionTable/partition-level recoveryOracle Multitenant support
• Tape and cloud backups• Unified Management
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Recovery Appliance Recommended
25
CloudStorage
Remote Replica
Tape
End-to-End Oracle Recovery ValidationNear Zero Data Loss for DR
Day 1 Full
a
Day 2 Changes
Day N ChangesVirtual Full Backup
EM Real-Time Protection Status
& Space Monitoring
Day 1 StateDay 2 StateDay N State
Databases
Transactional Block Changes
No More Full Backups,Incremental Forever
Oracle DB 12c-19c on Any Platform
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Database and Exadata Health Checks
Assessment Report• Health Score, Summary,
Findings
Findings & Recommendations• How to Solve the problem?
MAA Score Card• MAA architectural readiness
and configuration practices
26
Note: Automated Orachk/Exachk Healthcheck MOS 107954.1 updated frequentlyCopyright © 2020, Oracle and/or its affiliates | Confidential: Public
Online OperationsOnline Redefinition Improvements
DBMS_REDEFINITION allows you to reorganize and redefine tables online• Add/drop/rename/reorder columns• Switch physical storage structures• Reorganize & transform data while online
Additional Benefits of using DBMS_REDEFINITION• 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
27
Source Table
Update Tracking
Transform CopyTable
TransformUpdates
Result Table
Continuous Queries & Updates
Store Updates
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Online OperationsAll Partition Maintenance Operations are now Online
28
11.2 & Prior Create index online, rebuild index online, rebuild index partition onlineAdd Column, Add Constraint enable novalidate
12.1 Online move partitionDrop index onlineSet unused column online, alter column visible/invisible, alter index unusable online, alter index visible/invisible alter index parallel/noparallel
12.2 Alter table move online for non-partitioned tablesAlter table from non-partitioned to partitioned onlineAlter table split partition onlineCreate table for exchange (usable for online partition exchange)Move/merge/split partition maintenance operations can now do data filtering
18.1, 19c Alter table modify partitioned table to a different partitioning method (e.g., hash to range)Alter table merge partition/sub-partition online
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Flashback TechnologiesRewind Button for Oracle Databases
29
• 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
@T2 Col-1 Col-.. Col-n
Row-1 tom 1234 vp
Row-2 ben 8834 vp
Row-3 charlie 9837 vp
Row-n tom 8793 vp
@T1 Col-1 Col-.. Col-n
Row-1 abby 1234 officer
Row-2 ben 8834 mgr
Row-3 Charlie 9837 officer
Row-n tom 8793 vp Wrong Update
Flashback Table
DB @ T1 DB @ T2
Batch Update
Flashback Database
Wrong Update
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
f1: RPO=0 unless explicitly specifiedf2: To achieve zero downtime or lowest impact, apply application checklist best practices
Prod/Departmental
SILVER
Bronze +• Real Application Clustering (RAC)• Application Continuity
Outage Matrix
RAC Database
Primary Availability Domain Secondary Availability Domain
Local Backup
Replicated Backups
Checklist found in MAA OTN https://www.oracle.com/technetwork/database/options/clustering/applicationcontinuity/adb-continuousavailability-5169724.pdf
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
Planned Maintenance
Software/Hardware updates Zero (f2)
Major database upgrade Minutes to hour
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public30
Multitenant and RAC: Affinity
• Single CDB• Two-node RAC cluster• Single RAC instance per node• PDB’s affinity to a RAC
instance defined by starting its services there• Present in “mounted” state
in other nodes
PDB1 PDB2 PDB3 PDB4 PDB5 PDB6
RAC Cluster
SingleCDB / SharedStorage
Inst1
Inst2
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public31
PDB1 PDB2 PDB3 PDB4
RAC Cluster
Inst1
Inst2
Multitenant and RAC: Scalability and Agility
• Expand cluster• Redistribute PDBs
• Use Srvctl
PDB5 PDB6
SingleCDB / SharedStorage
Inst3
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public32
Multitenant and RAC: Scalability and Agility
• Single CDB• Single instance per node• PDBs may be configured with
“singleton” affinity to a specific RAC node• Present in “mounted” state
in other RAC nodes• PDBs may be open in multiple
RAC nodes
PDB7 PDB8PDB1 PDB2 PDB3 PDB4 PDB5 PDB6
SingleCDB / SharedStorage
RAC Cluster
Inst1
Inst2
Inst3
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public33
Singleton Affinity of PDB to Instance in RAC Cluster
• Per-PDB lock domain provides strong isolation
• Cache Fusion following instance failure can ignore PDBs not open in affected nodes
PDB1 PDB2 PDB3 PDB4 PDB5 PDB6 PDB7 PDB8
RAC Cluster
Inst1
Inst2
Inst3
Inst4
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public34
Multitenant and RAC: Availability
PDB1 PDB2 PDB3 PDB4 PDB5 PDB6 PDB7 PDB8 PDB9 PDB10 PDB11 PDB12
RAC Cluster
Inst1
Inst2
Inst3
Inst4
P PP
MM A
M
M M
MA
A
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public35
Oracle Real Application Clusters (Oracle RAC)Node Failure, Instance Failure, Rolling Maintenance
36
• Utilizes two or more instances of an Oracle Database concurrently
• Very Scalable• All instances active; Add capacity online; Ideal for
database consolidation
• Highly Available• Auto-failover of services to an already running
instance; Outage is transparent to user, in-flight transactions succeed; Zero downtime rolling maintenance
Database Tier
ApplicationTier
Database Services
Primary Database
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Transparent Application Continuity (TAC)Application does not see errors during outages
Request
Errors/Timeouts hidden
Transparent Application Continuity
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
• Uses Application Continuity and Oracle Real Application Clusters
• 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 transactions upon unplanned failure
• Planned maintenance can be handled by TAC to drain sessions from one or more nodes
• Adapts as applications change: protected for the future
37
Planned Maintenance
3
1
4
6
5
Planned Maintenance (without Outages!):1. Database Service is relocated or stopped
2. Service starts on another RAC instance
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
6. Maintenance activities can start on first node (rolling)2
RAC ClusterCopyright © 2020, Oracle and/or its affiliates | Confidential: Public38
Unplanned Outages, without Impact
Primary
1 2
3
Outage or Interruption at Database:
1. Database Request interrupted by an Outage or timeout
2. Session reconnects to the RAC Cluster
3. Database Request replays automatically
4. Result from Database Request returned to user
4
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public39
Checklist for Achieving Zero Application Downtime
1. Use Oracle Clusterware Service (never use default service)2. Use Recommended Connection String3. Configure FAN for Connection Pool4. Drain your service 5. Use Application Continuity or Transparent Application Continuity
1) MAA Whitepaper: Application Checklist for Continuous Service for MAA Solutions2) Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata
(MOS 2385790.1)3. Fleet Patch and Provisioning incorporates MAA practices
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public40
Introducing the “Aurous” MAA OptionMultitenant Architecture-based Disaster Recovery
Flexible PDB Placement using Refreshable PDB Switchover• Great HA and PDB flexibility. Good data protection & DR.
• 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 read-only standby, automatic DR failover and fast reinstate after role transition
• Capability is very innovating but relatively new
• RTO=secs for HA and RTO < 30 mins for DR • RPO for DR < 15 mins
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public41
Picking MAA Reference Architecture (Aurous option included)
MAA Reference Architecture
RTO for HA /Downtime for Software Updates
RTO for DR /Downtime for DB Upgrades
RPO for DR On-Premise Oracle Cloud
Bronze MAA Hour(s) Hours < 30 mins*Secs with ZDLRA
Yes Yes
Silver MAA Zero or Secs Hours < 30 mins*Secs with ZDLRA
Yes –Exadata, RAC
Yes- ExaCS, ExaCC, ADB
“Aurous” Option Zero or Secs < 30 mins < 15 mins *Secs with ZDLRA
Yes No
Gold MAA Zero or Secs < 2 mins Zero or secs Yes Yes – ExaCS **
Future – ADB, ExaCC
Platinum MAA Zero or Secs Zero or secs Zero or secs Yes Yes – ExaCS/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. Not 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 log backup and refresh frequency. With ZDLRA, seconds. ZDLRA is available for On-premise and ExaCC** Limitations described later but setup is mostly manual
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public42
The “Aurous” MAA Strategy
• CDB can have a mix of primary & DR copy PDBs
• Individual PDBs can transition roles independently
• Standby PDBs are mounted
Trade-offs in comparison to Gold MAA tier:• No read-only query offloading• No automatic block repair• No zero data loss when primary not accessible• No automatic failover capabilities• Requires significantly more manual
configuration steps• No application continuity
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public43
Refreshable PDBs as ReplicasPer-PDB replica with only two CDBs to manage!
44
Server1
CDB1
CDB2
Server2
Replication
Repl
icat
ion
1. create pluggable database Red;4. create pluggable database Brown;6. create pluggable database Grey
from Grey@CDB2_Linkrefresh mode every 10 minutes;
2. create pluggable database Redfrom Red@CDB1_Linkrefresh mode every 10 minutes;
3. create pluggable database Gold;5. create pluggable database Grey;
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Refreshable PDB SwitchoverPlanned switchover
45
Server1
CDB1
CDB2
Server2
Replication
1. alter pluggable database Greyrefresh mode every 10 minutesfrom Grey@dblink switchover;
Repl
icat
ion
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Refreshable PDB SwitchoverUnplanned switchover
46
Server1
CDB1
CDB2
Server2
Replication
Replication 1. alter pluggable database Greyrefresh;
2. alter pluggable database Greyrefresh mode none;
3. alter pluggable database Greyopen read write;
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
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 refreshBest practices:
• Relatively high frequency of refresh (minutes rather than hours)• Thorough testing with realistic transaction volumes
47 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Multitenant “Aurous” MAA Strategy
48
Unplanned Outages Key Features for Solution RTO RPO
Recoverable node or instance failure Real Application Cluster (RAC)Application Continuity (AC/TAC)
Secs Zero
Disasters: corruptions and site failures Many Refreshable PDB Switchover operations
Not automatic(< 30 mins) but timings may not be scalable for DR
Since last refresh (< 15 mins)PDB unrecoverable failure or “sick” PDB Refreshable PDB Switchover
Planned Maintenance Solution RTO
Software and hardware updates RAC, AC or TAC Zero
Major database upgrade Many PDB Relocate + Upgrade < 20 Minutes
Migration to remote CDB PDB Relocate Minutes
Migration to remote CDB (logical migration) Data Pump and GoldenGate Potentially Zero
Migration plus upgrade PDB Relocate + Upgrade 10 Minutes
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
f1: RPO=0 unless explicitly specifiedf2: To achieve zero downtime or lowest impact, apply application checklist best practices
Outage Matrix
Primary Region Secondary Region
Local backup
Remote StandbyPrimaryLocal
StandbyLocal
backup
AD2 AD1
Mission Critical
Silver +• Active Data Guard
• Comprehensive Data ProtectionMAA Architecture: • At least one standby required
across AD or region. • Primary in one data center(or AD)
replicated to a Standby in another data center
• Active Data Guard Fast-Start Failover (FSFO)
• Local backups on both primary and standby
GOLD DG FSFO
Unplanned Outage RTO/RPO Service Level Objectives (f1)
Recoverable node or instance failure Single digit seconds (f2)
Disasters: corruptions and site failures Seconds to 2 minutes. RPO zero or seconds
Planned Maintenance
Software/Hardware updates Zero (f2)
Major database upgrade Less than 30 seconds
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public49
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
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public50
Storage Remote Mirroring Architecture
51
Generic - Must Transmit Writes to All Files …. INCLUDING CORRUPTED BLOCKS OR BAD DATA
Oracle Instance (in memory)
Primary Database Mirrored Volumes
SYNC or ASYNCblock replication
• Zero Oracle validation• 7x network volume• 27x network i/o
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Active Data Guard: Advanced Capabilities
Copyright © 2019 Oracle and/or its affiliates.
Zero data loss at any distance
Automatic Block Repair
Data Guard Broker(Enterprise Manager Cloud Control or DGMGRL)
Offload Fast Incremental
Backups
DML Redirection
Offload read-mostly workload to open standby
database
Primary Data Center DR Data Center
DBMS_ROLLING
APP CONT
Application Continuity
Application Continuity
Primary DatabaseFar Sync Instance
Active Standby Database• Oracle control file and log files• No database files• No media recovery• Offload transport compression and/or
encryption
• Zero data loss failover target• Database open read-only• Continuous Oracle validation• Manual or automatic failover
SYNCLimited distance
ASYNCAny distance
Redo compressed over WAN
Active Data Guard Far SyncZero Data Loss Protection at Any Distance
53
• Production copy
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Unplanned Outages, without Impact expanded to the Standby
Primary Active Data Guard Standby
1 2
3
Outage or Interruption at Database:
1. Database Request interrupted by an Outage or timeout
2. Session reconnects to the RAC Cluster (or Standby) and
3. Database Request replays automatically
4. Result from Database Request returned to user
4
2
3
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public54
Extend Footprint of ADG Applications Support for DML Re-direction
55
• 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
supported for Oracle Database 19c
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Multi-Instance Redo Apply Performance
• Utilizes all RAC nodes on the Standby database to parallelize recovery• OLTP workloads on Exadata show great scalability
56
Lower Latency Active Data Guard Standby Databases
190 380 7401480700
1400
2752
5000
0
1000
2000
3000
4000
5000
6000
7000
1 Instance 2 Instances 4 Instances 8 Instances
Batch
OLTP
StandbyApplyRate
MB/sec
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
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
57
Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Multitenant Replication Capabilities
58
Manage many as one with Data Guard
(Standbys= None)
PDB4PDB3PDB1 PDB2
Server1
Primary
PDB3’PDB1’ PDB2’
Server2
Standby
Dat
a G
uard
Rep
licat
ion
• When creating new local PDBs, the new PDBs are automatically replicated and represented on the standby.
• What happens when cloning a remote PDB or plugging in new PDBs?
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
What if only one PDB is down or needs to be relocated?
• PDB failover is possible by migrating to a new CDB. • PDB relocate can be used move a PDB to another CDB (same release or different release)
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public63
PDB Failover: Normal Runtime
PDB1 PDB2CDB 1
Read-WriteCDB 1StandbyRead- OnlyData Guard
CDB 2Read-Write
PDB4
PDB2 PDB3PDB1 PDB3
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public64
PDB Failover after PDB 2 OutageUnplug/plug PDB2 from CDB1 standby to CDB2 and failover application connections
PDB1
CDB 1Read-Write
CDB 1StandbyRead- OnlyData Guard
CDB 2Read-Write
PDB4
PDB2PDB1 PDB2 PDB3 PDB3
PDB2
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public65
Online PDB Relocation
Online PDB Relocation• Relocate with minimal downtime
CRM
HR
Oracle Cloud
Pricing Retail
On-Premises
CRM
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public66
Multitenant “Gold” MAA Strategy
67
Unplanned Outages Key Features for Solution RTO RPO
Recoverable node or instance failure Real Application Cluster (RAC)Application Continuity (AC/TAC)
Secs Zero
Disasters: corruptions and site failures Active Data Guard Fast-Start Failover
< 2 mins Zero or Secs
PDB unrecoverable failure or “sick” PDB PDB Failover (unplug/plug)Another target CDB on the same cluster required (MOS 2088201.1)
< 2 mins Zero or Secs
Planned Maintenance Solution RTO
Software and hardware updates RAC, AC or TAC Zero
Major database upgrade Active Data Guard DBMS_ROLLING Secs
Migration to remote CDB PDB Relocate Mins
Migration to remote CDB (logical migration) Data Pump and GoldenGate Potentially Zero
Migration plus upgrade PDB Relocate + Upgrade < 10 Minutes
Updated MAA Best Practices Papers: Best Practices For Database Consolidation On Oracle Exadata Database Machine
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
f1: RPO=0 unless explicitly specified f2: To achieve zero downtime or lowest impact, apply application checklist best practices f3: Application failover is custom or with Global Data Services
Gold +• GoldenGate Active/Active
Replication• Optional Sharding & Editions Based
Redefinition MAA Architecture: • Each GoldenGate “primary” replica
protected by Exadata, RAC and Active Data Guard
• Primary in one data center (or AD) replicated to another Primary in remote data center (or AD)
• Oracle GG & Editions Based Redefinition for zero downtime application upgrade
• Sharding for scalability and fault isolation
• Local backups on both sites• Achieve zero downtime through
custom failover to GG replica
Extreme Critical
PLATINUM Primary Region Secondary Region
Local backup
Local backup
AD2 AD1
GG Replication
AD1 AD2
Standby StandbyPrimary Primary
Outage MatrixUnplanned Outage RTO/RPO Service Level Objectives
(f1)
Recoverable node or instance failure Zero or single digit seconds (f2/f3)
Disasters including corruptions and site failures Zero (f3)
Planned Maintenance
Most common software/hardware updates Zero (f2)
Major database upgrade, application upgrade Zero (f3)
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public70
GoldenGate plus 2 Optional Approaches to Further Protect Your Applications
71
Use Edition-based Redefinition Use Oracle ShardingUse Oracle Golden Gate
Required Optional Alternative
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
GoldenGate plus 2 Optional Approaches to Further Protect Your Applications
72
Use Edition-based Redefinition Use Oracle ShardingUse Oracle Golden Gate
Required Optional Alternative
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Oracle GoldenGate Microservices Architecture
73
SourceOracle & Non-OracleDatabase(s)
TargetOracle & Non-Oracle
Database(s)
Capture: committed transactions are captured (and can be filtered) as they occur by reading the transaction logs.
Trail: stages and queues data for routing.
Distribution Server/Receiver: distributes data for routing to target(s).
Route: data is compressed, encrypted for routing to target(s).
Capture
Delivery
TrailFiles Dist.
Service
TrailFiles
Delivery
Capture
Bi-directional
LAN / WAN / InternetOver TCP/IP
TrailFiles
TrailFiles
Delivery: applies data with transaction integrity.
Dist. Service
Receiver Service
Receiver Service
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Key GoldenGate Improvements Simplify Platinum
1. GoldenGate Hub simplifies migration and administration by offloading work from source and target
• New GoldenGate cloud market place automates GG hub deployment• Cross endianness capture enables cross platform migration• Upcoming Zero Downtime Migration integration with GoldenGate
2. GoldenGate Microservices simplifies administration and management
74
Oracle Database Migration with an Oracle GoldenGate Hub Configuration
Oracle GoldenGate Microservices Architecture with Oracle Real Application Clusters Configuration Best Practices
Future: Zero Downtime Migrationwww.oracle.com/goto/zdm
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Oracle GoldenGateMAA Best Practices
• Transparent Role Transitions in Data Guard Configurations• No manual intervention required with FSFO and DG Broker
• Configuration makes use of:• Oracle Grid Infrastructure Bundled Agent (XAG)• DBFS or ACFS for shared GoldenGate files (trails and checkpoint files)• Role based services• Integrated Extract (with HANDLEDLFAILOVER option for ASYNC DG)• Microservices Architecture for simpler administration
75
Updated: MAA Best Practice Paper: Transparent Role
Transitions with Data Guard and Oracle GoldenGate
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Data Center Architecture & Requirements
• A minimum of 2 Regions for Disaster Recovery Failover• Region is a localized geographic area• West Coast NAS – Primary example• East Coast NAS – Secondary example
• Each Region should have a minimum of 2 Availability Domains (AD)
• Availability Domain Characteristics• AD’s are isolated from each other & fault
tolerant• AD’s do not share infrastructure such as power,
cooling or AD Network• A failure of one AD does not effect other AD’s.• AD’s within a Region are connected via high
speed network within same geographical area.
AD1 AD2
Primary Region – West NAS
AD1 AD2
Secondary Region – East NAS
High Speed with < 1ms LatencyCopyright © 2020, Oracle and/or its affiliates | Confidential: Public76
Sample Deployment
77
Observer
Primary Database Standby Database
ADG Redo Transport(SYNC or ASYNC)
Integrated Extract
LogMiningServer
Trail and other OGG FilesIn DBFS
Redo Transport
OCI Connection
File I/OWarehouse
BidirectionalGoldenGate Replication
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Sample Deployment – Post Role Transition
78
Observer
(OLD) Primary Database (NEW) Primary Database
ADG Redo Transport(SYNC or ASYNC)
Integrated Extract
LogMiningServer
Trail/Checkpoint/BR FilesIn DBFS
LogMiningServer
Warehouse
BidirectionalGoldenGate Replication
Redo Transport
OCI Connection
File I/O
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
GoldenGate plus 2 Optional Approaches to Further Protect Your Applications
79
Use Edition-based Redefinition Use Oracle ShardingUse Oracle Golden Gate
Required Optional Alternative
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Edition-Based RedefinitionOnline Application Upgrade
• Enables application upgrades to be performed online• Code changes installed in the privacy of a new edition• Data changes are made safely by writing only to new columns or new
tables not seen by the old edition• An editioning view exposes a different projection of a table into each
edition to allow each to see just its own columns• A cross-edition trigger propagates data changes made by the old edition
into the new edition’s columns, or (in hot-rollover) vice-versa
80 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
GoldenGate plus 2 Optional Approaches to Further Protect Your Applications
81
Use Edition-based Redefinition Use Oracle ShardingUse Oracle Golden Gate
Required Optional Alternative
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Alternate Platinum Option: ShardingHighly scalable, fault tolerant architecture for Internet Applications
82
• Custom Built Application optimized to use shard keys
• Horizontal partitioning of data across independent databases (shards)– Each shard holds a subset of the data– Can be single-node or RAC or PDB– Replicated for high availability
• Shared-nothing architecture:– Shards don’t share any hardware (CPU,
memory, disk), or software (Clusterware)
A single logical DB sharded into N physical Databases
Server1
Database
Table1Shard1
Server2
Table1Shard2
Server3
Table1Shard3
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Clients
Data GuardFast-Start Failover
RegionAvailabilty_Domain1
Shard Catalogshardcat_stdby
Shard Directorshdir3,4
RegionAvailability_Domain2
Shardgroupshgrp2
Shardgroupshgrp1
…
…
Shard Directorshdir1,2
Shard Catalogshardcat
Connection Pools
Connection Pools
Primaries
HA Standbys
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Deployment of a System-Managed SDB with Active Data Guard
83
Sharding Configuration OptionsUse Sharding with Active Data Guard, RAC or Oracle GoldenGate
84
Active Data Guard with Fast-Start Failover
GoldenGate ‘chunk-level’ active-active replicationwith automatic conflict detection/resolution
Optionally – complement replication with Oracle RAC for server HA
https://www.oracle.com/database/technologies/high-availability/sharding.htmlCopyright © 2020, Oracle and/or its affiliates | Confidential: Public
Maximum Availability Architecture (MAA)
Summary & Resources
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public85
External Resources
Maximum Availability Architecture • 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
86 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Provide the best HA, DR and data protection solution for Oracle databases
Continue to enhance validated MAA solutions
Your success is truly our success!!!
Copyright © 2020, Oracle and/or its affiliates | Confidential: Public87
Our mission is to help peoplesee data in new ways, discover insights,unlock endless possibilities.