Maximum Availability Architecture - Best Practices for Oracle Database 19c

Oracle Maximum Availability Architecture (MAA) Blueprints for reduced planned and unplanned downtime for the On-Premises, Exadata-based or Cloud-base Oracle Database Glen Hawkins Senior Director of Product Management, MAA & Data Guard June, 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

40% of businesses fail to reopen after experiencing a disaster Downtime is Prevalent and Businesses are at Risk 75% of small to medium sized business don’t have a disaster recovery plan in place 91% of companies have experienced unplanned data center outages in the past 24 months 7 Source: https://informationprotected.com/stud y-40-percent-businesses-fail-reopen- disaster/ Source: http://gazette.com/7- shocking-disaster-recovery-stats- for-small-business- owners/article/1590436 Source: https://www.healthitoutcomes.com/d oc/beware-the-high-cost-of-data- center-outages-0001 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public5

Oracle Maximum Availability Architecture (MAA) Reference Architecture s Deployment Choices HA Features, Configurations & Operational Practices 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 Generic Systems Engineered Systems DBCS ExaCS/ExaCC Autonomous DB Active Replication Active Data Guard GoldenGate Scale Out RAC ShardingASM Copyright © 2020, Oracle and/or its affiliates | Confidential: Public7

Meet Downtime (RTO) and Data Loss (RPO) SLAs MAA Reference Architectures Downtime&DataLoss BRONZE Single Instance + Backup Dev, Test, Prod SILVER HA Clustering + Backup Prod/Departmental GOLD HA Clustering + Disaster Recovery + Backup Mission Critical PLATINUM Zero Data Loss & Zero Downtime Extreme Critical MAA Reference Architectures Topology Suitable Databases Addresses SLAs for Data Loss and Downtime during Planned & Unplanned Outages Copyright © 2020, Oracle and/or its affiliates | Confidential: Public8

Designed to Address the Complete Range of Business Requirements Oracle MAA Common Platform – On Premises, Cloud, and Hybrid Cloud Big Differentiator On Premises On Cloud Oracle Database Copyright © 2020, Oracle and/or its affiliates | Confidential: Public9

Outage Matrix Single Instance Database Primary Availability Domain Secondary Availability Domain Local Backup Replicated Backups Dev, Test, Prod - Single Instance or Multitenant Database with Backups • Single Instance with Clusterware Restart • 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 (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 specified f2 : Exadata systems has RAC but Bronze Exadata configuration with Single Instance database running with Oracle Clusterware has highest consolidation density to reduce costs 11 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public11

• Oracle Multitenant means self-contained, Pluggable Databases (PDBs) providing - Online portability - PDB upgrades (using plug / unplug) - Rapid provisioning (using clones) • PDBs enable transparent, simplified online lifecycle operations for any application • PDBs provide “manage many as one” benefits in consolidated environments • Apply backups, create standby databases and recovery to all pluggable databases in the container • Speed up database migration to new container databases (in the cloud) Oracle Multitenant Architecture for consolidating databases and simplifying lifecycle operations 12 Pricing Retail CRM Copyright © 2020, Oracle and/or its affiliates | Confidential: Public

Database Integrated Backup and Recovery Oracle Recovery Manager - RMAN 13 • 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 RMAN Data Files Fast Recovery Area (FRA) Cloud Tape Disk Tape Copyright © 2019 Oracle and/or its affiliates.

Recovery Appliance Recommended Cloud Storage Remote Replica Tape End-to-End Oracle Recovery Validation Near Zero Data Loss for DR Day 1 Full a Day 2 Changes Day N Changes Virtual 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: Public14

Online Operations 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 Online Redefinition Improvements Source Table Update Tracking TransformCopy Table Transform Updates Result Table Continuous Queries & Updates Store Updates Copyright © 2020, Oracle and/or its affiliates | Confidential: Public15

Flashback Technologies • 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 Rewind Button for Oracle Databases @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: Public16

f1: RPO=0 unless explicitly specified f2: 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/op tions/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 17 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public17

Oracle Real Application Clusters (Oracle RAC) • 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 Application Tier Database Services Primary Database Node Failure, Instance Failure, Rolling Maintenance Copyright © 2020, Oracle and/or its affiliates | Confidential: Public18

Application does not see errors during outages Transparent Application Continuity (TAC) • 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 Request Errors/Timeouts hidden Transparent Application Continuity 19 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public19

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 Cluster 20 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public20

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 21 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public21

f1: RPO=0 unless explicitly specified f2: To achieve zero downtime or lowest impact, apply application checklist best practices Outage Matrix Primary Region Secondary Region Local backup Remote Standby Primary Local Standby Local backup AD2 AD1 Mission Critical Silver + • Active Data Guard • Comprehensive Data Protection MAA 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: Public22

Active Data Guard Overview Primary Open Read-Write Standby Open Read-Only Zero Data Loss at any Distance Automatic Block Repair Offload read only or read mostly workloads to the standby database • Synchronous zero data loss replication • Database rolling upgrade to reduce downtime for planned maintenance • Automatic failover for High Availability DML Redirection Multi-instance Redo Apply for RAC (In Memory supported) Copyright © 2020, Oracle and/or its affiliates | Confidential: Public23

Primary Database Far 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 SYNC Limited distance ASYNC Any distance Redo compressed over WAN Zero Data Loss Protection at Any Distance Active Data Guard Far Sync • Production copy Copyright © 2020, Oracle and/or its affiliates | Confidential: Public24

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 25 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public25

Extend Footprint of ADG Applications • 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 Support for DML Re-direction Copyright © 2020, Oracle and/or its affiliates | Confidential: Public26

Lower Latency Active Data Guard Standby Databases Multi-Instance Redo Apply Performance 190 380 740 1480700 1400 2752 5000 0 1000 2000 3000 4000 5000 6000 7000 1 Instance 2 Instances 4 Instances 8 Instances Batch OLTP • Utilizes all RAC nodes on the Standby database to parallelize recovery • OLTP workloads on Exadata show great scalability Standby Apply Rate MB/sec Copyright © 2020, Oracle and/or its affiliates | Confidential: Public27

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 Matrix Unplanned 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: Public28

Use Edition-based Redefinition Use Oracle Sharding GoldenGate plus 2 Optional Approaches to Further Protect Your Applications Use Oracle Golden Gate Required Optional Alternative Copyright © 2020, Oracle and/or its affiliates | Confidential: Public29

Alternative Use Oracle Sharding Optional Use Edition-based Redefinition GoldenGate plus 2 Optional Approaches to Further Protect Your Applications Use Oracle Golden Gate Required Copyright © 2020, Oracle and/or its affiliates | Confidential: Public30

Oracle GoldenGate Microservices Architecture Source Oracle & Non-Oracle Database(s) Target Oracle & 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 Trail Files Dist. Service Trail Files Delivery Capture Bi-directional LAN / WAN / Internet Over TCP/IP Trail Files Trail Files Delivery: applies data with transaction integrity. Dist. Service Receiver Service Receiver Service Copyright © 2020, Oracle and/or its affiliates | Confidential: Public31

Oracle GoldenGate • 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 MAA Best Practices Updated: MAA Best Practice Paper: Transparent Role Transitions with Data Guard and Oracle GoldenGate Copyright © 2020, Oracle and/or its affiliates | Confidential: Public32

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 Latency 33 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public33

Sample Deployment Observer Primary Database Standby Database ADG Redo Transport (SYNC or ASYNC) Integrated Extract LogMining Server Trail and other OGG Files In DBFS Redo Transport OCI Connection File I/O Warehouse Bidirectional GoldenGate Replication Copyright © 2020, Oracle and/or its affiliates | Confidential: Public34

Sample Deployment – Post Role Transition Observer (OLD) Primary Database (NEW) Primary Database ADG Redo Transport (SYNC or ASYNC) Integrated Extract LogMining Server Trail/Checkpoint/BR Files In DBFS LogMining Server Warehouse Bidirectional GoldenGate Replication Redo Transport OCI Connection File I/O Copyright © 2020, Oracle and/or its affiliates | Confidential: Public35

Edition-Based Redefinition • 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 Online Application Upgrade Copyright © 2020, Oracle and/or its affiliates | Confidential: Public37

Alternate Platinum Option: Sharding Highly scalable, fault tolerant architecture for Internet Applications • 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 Table1 Shard1 Server2 Table1 Shard2 Server3 Table1 Shard3 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public39

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 Copyright © 2020, Oracle and/or its affiliates | Confidential: Public41

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

Our mission is to help people see data in new ways, discover insights, unlock endless possibilities.

Maximum Availability Architecture - Best Practices for Oracle Database 19c

More Related Content

What's hot

Similar to Maximum Availability Architecture - Best Practices for Oracle Database 19c

Recently uploaded

In this document

Maximum Availability Architecture - Best Practices for Oracle Database 19c