Plan DR for Databases

You can use Oracle GoldenGate, Active Data Guard, and Autonomous Data Guard to implement DR for your databases deployed in Oracle Cloud.

• Active Data Guard provides comprehensive data protection, high availability, and disaster recovery for Oracle Database in a simple and economical manner by maintaining a synchronized physical replica (standby) of a production database at a remote location. The standby database is open read-only during redo transfer, validation, and recovery.

  Unlike typical storage replication methods, Active Data Guard replicates only the in-memory redo logs, and validates the replication to prevent any chance of corruption.

• Oracle GoldenGate is an advanced logical replication product that supports multimaster replication, hub and spoke deployment, and data transformation. GoldenGate provides customers flexible options to address the complete range of replication requirements, including heterogeneous hardware platforms.
• Autonomous Data Guard provides data protection and disaster recovery for your autonomous database instances in Oracle Cloud. When you enable Autonomous Data Guard for an autonomous database instance, a standby database is created in the same region. In regions with more than one availability domain, the standby is provisioned in a different availability domain than the primary database. In regions with a single availability domain, the standby is provisioned on a different physical machine than the primary database. Autonomous Data Guard monitors the primary instance, and automatically fails over to the standby database if the primary database becomes unavailable.

About Oracle Maximum Availability Architecture

Oracle Maximum Availability Architecture (MAA) is a set of best practices blueprints for the integrated use of Oracle’s high availability technologies. The MAA best practices describe standard architectures designed to achieve different service level objectives for high availability and data protection requirements. The Bronze, Silver, Gold, and Platinum MAA architecture tiers are designed to achieve different service level objectives and provide you with options for high availability, data protection, and disaster recovery.

Each of the following MAA tiers uses an optimal set of Oracle capabilities that, when deployed together, reliably achieve target service levels for unplanned outages and planned maintenance events:

• Bronze

  The Bronze tier provides basic database service at the lowest possible cost. A reduced level of high availability and data protection is accepted in exchange for reduced cost and implementation complexity. This architecture may be suitable for databases used for test, development, and less critical production applications and databases.

  The architecture uses the high availability capabilities included in Oracle Enterprise Edition. Bronze defaults to the Oracle Database single-instance or multitenant architecture. Oracle Restart or Oracle Clusterware high availability capabilities are used to restart a failed instance, database server, or any relevant managed service. For logical corruptions such as human error, you can use Flashback operations to “rewind” the database to a specific point in time. In the worst-case scenario of a complete site outage, there is additional time required to restore and recover the system and database from backups which may result in hours or days of downtime.

  A local backup within the same data center is always recommended for the fastest recovery. Oracle also recommends maintaining a second copy of backups in a remote data center to protect against site outages and disasters. You can use Oracle Database Backup Cloud Service to maintain a cloud-based backup of on-premises databases.

• Silver

  The Silver tier is designed for databases that can’t afford to wait for a cold restart or a restore from backup, should there be an unrecoverable database instance or server failure. This architecture may be suitable for production applications that are business critical and need to reduce downtime for local failures and most common planned maintenance activities.

  The Silver architecture is built on the foundation of the Bronze architecture, and adds Oracle Real Application Clusters (Oracle RAC) active-active clustering for minimal or zero downtime in the event of database instance or server failure, as well as zero database downtime for most common planned maintenance events.

  Just like in the Bronze architecture, Recovery Manager (RMAN) provides database-optimized backups to restore availability should there be a complete cluster outage or disaster.

• Gold

  The Gold tier is designed for service level requirements that can't tolerate long periods of downtime and data loss. This set of architecture patterns provides high availability and comprehensive data protection for all types of unplanned outages, including data corruptions, database failures, and site outages. Mission critical production applications that require quick recovery time and zero or minimal data loss for all database and system outages and planned maintenance activities will benefit from the capabilities included in the Gold reference architecture.

  The Gold reference architecture, building on the Silver reference architecture, provides you with four architecture patterns using Oracle Active Data Guard. The patterns vary from a single remote active standby with Fast Start Failover and HA Observer, to multiple standby database configurations including standby reader farms, and finally a far sync (across regions) zero data loss standby configuration.

• Platinum

  The Platinum tier has the potential to provide zero downtime for outages and planned maintenance activities that are not achievable with the Gold architecture. The Platinum architecture builds on the Gold architecture by adding Oracle GoldenGate replication to eliminate downtime for migrations, application upgrades, and database upgrades. Each Oracle GoldenGate database is protected by a standby database to enable zero data loss in case of database, cluster, or site failure.

  Unlike the other MAA architectures, application considerations are required to integrate Oracle GoldenGate into the architecture, to ensure that conflict detection and resolution are performed properly. Global Data Services, or custom application service management, may also be required to achieve zero application downtime for activities such as migration and database upgrades.

Use Active Data Guard

Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. The majority of Active Data Guard best practices are defined, tested, and validated as part of reference architectures in the MAA Gold tier.

If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

Benefits of Active Data Guard

Active Data Guard provides several benefits.

• Secure physical replication.

  The standby database is open read-only so your data consistency is guaranteed.

  Note that starting with Oracle Database 19c, you can issue occasional update and insert instructions to the standby database, which redirects the instructions to the primary database.

• Simple, fast, one-way replication of a complete Oracle Database.

  The default configuration handles most workloads so there’s little administrative overhead.

• No restrictions.

  Oracle Data Guard Redo Apply supports all Oracle features and transparently replicates all data and storage types, PL/SQL packages, and DDL without special considerations.

• Best data protection.

  Replication direct from memory isolates the standby database from I/O corruption that can occur at the primary database. Detects silent lost-write corruption that can occur independently on the primary or standby database. Automatically detects and repair physical block corruption that can occur independently on the primary or standby database.

• Choice of synchronous with zero data loss, or asynchronous with near-zero data loss protection.
• Improved RoI.

  You can offload read-only workloads such as reporting applications, ad-hoc queries, and data extracts to a synchronized physical standby.

• A single command converts a physical standby database as a test system open read/write. A second command converts it back to a physical standby database and resynchronizes it with the primary database. Primary data is always protected.
• Integrated management of a complete configuration with Oracle Data Guard Broker command line, and automatic database failover.
• Supported for single-node database or multiple-node database (Real Application Cluster) configuration.
• Application Continuity, for in-flight protection of your transactions.

  Active Data Guard masks database outages from end users and applications by recovering the in-flight work for impacted database sessions.

Configuration Modes

• Maximum Protection
  This protection mode provides zero data loss if the primary database fails. To ensure that data loss can’t occur, the primary database shuts down if a fault prevents it from writing its redo stream to the standby redo log of at least one standby database.

  Note:

  This mode is not available for autonomous databases. For Exadata Cloud Service and Exadata Cloud@Customer, you can configure this mode manually, but the cloud control plane won't reflect it.
• Maximum Availability

  This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like the Maximum Protection mode, a transaction commits only after the redo needed to recover that transaction is written to the local online redo log and to the standby redo log of at least one transactionally consistent standby database. Unlike the Maximum Protection mode, the primary database doesn’t shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database and the Data Guard configuration are downgraded to the UNSYNCHRONIZED state. When at least one standby becomes available, the standby is resynchronized automatically.

• Maximum Performance

  This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit when the redo data needed to recover that transaction is written asynchronously to the local online redo log. When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of Maximum Availability mode with minimal impact on primary database performance.

DB Placement Considerations

To improve availability and disaster recovery, place the DB system of the standby database in a different availability domain than the DB system of the primary database.

If you enable Data Guard for a database and your standby database is in the same availability domain as the primary (either by choice, or because the region has a single availability domain), then place the standby database in a different fault domain than that of the primary database.

If your primary and standby databases are 2-node RAC virtual-machine DB systems and both are in the same availability domain, then we recommend distributing all four nodes (two for primary and two for standby) across all three fault domains in the availability domain. This configuration ensures the highest possible availability, taking advantage of all three fault domains. In this scenario, only one of the two nodes of the standby database can be in a fault domain that doesn’t include any other nodes from either the primary or standby database.

To ensure optimal role transitions between the primary database and the standby, Oracle recommends that you size and configure the two databases symmetrically.

Configuration Best Practices

See "Oracle Data Guard Best Practices" in Oracle Database High Availability Overview and Best Practices.

Use Oracle GoldenGate

Oracle GoldenGate is a comprehensive software package for real-time data integration and replication in heterogeneous IT environments. The product set enables high availability solutions, real-time data integration, transactional change data capture, data replication, transformations, and verification between operational and analytical enterprise systems. The majority of Oracle GoldenGate best practices are defined, tested, and validated as part of reference architectures in the MAA Platinum tier.

Use Oracle GoldenGate when a replica database must be open read/write while replication is active, including in the following scenarios:

• Advanced replication requirements, such as multimaster and bidirectional replication, subset replication, many-to-one replication, cross-endian replication, and data transformations
• Maintenance and migrations that require zero downtime using bi-directional replication
• Cross-platform migration that is not supported by Data Guard (for example, cross-endian platform migration)
• Support for cross-DB version distributed systems (for example, replica 1 is on 12.2 and replica 2 is on 19c)
• Support for cross-DB platforms (for example, replica 1 is on Oracle and replica 2 is on non-Oracle DB)

Configuration Modes

Use the Oracle GoldenGate Microservices architecture, which provides a secure, comprehensive, and scalable replication platform in the cloud. To minimize the overhead on the database servers, Oracle recommends that you deploy GoldenGate in the hub configuration.

GoldenGate supports several topologies, as shown in the following diagram. Choose a mode that suits your use case.

Description of the illustration gg-config-modes.png

Configuration Best Practices

Because Oracle GoldenGate replicates data on the transactional level, we recommend implementing Conflict Detection and Resolution (CDR) for data consistency between two sites. Conflicts are identified immediately and handled with automated scripts.

If you are using GoldenGate primarily for DR purposes and replication is only one way, then we recommend adding Data Guard between two regions. Doing so provides a zero-data-loss solution with strong data consistency between the primary and Data Guard instance. This configuration also alleviates the overhead of running GoldenGate extract from the primary database.

Description of the illustration db-dg-gg.png

Note:

The architecture shows multiple availability domains (ADs). For a region that has a single AD, adjust the architecture to distribute your resources across the fault domains within the AD.

Deploy Oracle GoldenGate as well in a HA configuration. You can use Oracle ASM Cluster File System (ACFS) replication for critical GoldenGate files.

Use Active Data Guard and GoldenGate

Oracle GoldenGate and Active Data Guard are not mutually exclusive. You can use them together to achieve a Recovery Point Objective (RPO) of zero (that is, no risk of data loss), because GoldenGate is asynchronous in nature while Active Data Guard can provide synchronous replication along with other key features such as data-block validation, automatic block repair, and application continuity.

The following are a few scenarios that leverage both Oracle GoldenGate and Active Data Guard:

• Use an Active Data Guard standby for disaster protection and database rolling upgrades for a mission-critical OLTP database. Use GoldenGate to extract data from the Data Guard primary database (or from the standby database using GoldenGate ALO mode) for ETL update of an enterprise data warehouse.
• Use GoldenGate subset replication to extract, transform, and aggregate data from numerous data sources into a central operational data store (ODS). The ODS supports mission-critical application systems that generate significant revenue for the company. Use an Active Data Guard standby database to protect the ODS, providing optimal data protection and availability.
• Use GoldenGate multimaster replication to synchronize several databases, each located in different geographies. Each GoldenGate copy has its own local synchronous Data Guard standby database that enables zero-data-loss failover if an outage occurs.

Note:

To implement the Platinum-level maximum availability architecture, use Oracle Real Application Clusters (Oracle RAC), Active Data Guard, as well as Oracle GoldenGate.