Disaster Recovery on Oracle Database Appliance Using Oracle Data Guard

Introduction to Oracle Database Appliance

Oracle Database Appliance is a pre-built, ready to deploy platform for Oracle Database.

Oracle Database Appliance systems are pre-built, pre-tuned, and ready-to-use non-clustered and clustered database systems that include servers, storage, networking, and software in an optimized configuration that makes them easy to deploy, operate, and manage. Oracle Database Appliance is a complete and ideal database platform for small, medium, and large-sized database implementations and incorporates robust, time-tested Oracle technologies, including the world-leading Oracle Database, the best-selling Oracle Real Application Clusters (Oracle RAC) database option, Oracle Clusterware, and Oracle Automatic Storage Management (Oracle ASM). By integrating hardware and software, Oracle Database Appliance eliminates the complexities inherent in non-integrated, manually assembled database solutions, reducing deployment time from weeks or months to just a few hours, while preventing configuration and setup errors that often result in sub-optimal, hard-to-manage database environments.

Description of the illustration oda_ha_model.png

Parent topic: Disaster Recovery on Oracle Database Appliance Using Oracle Data Guard

Data Protection Using Oracle Active Data Guard

Understand how Oracle Database Appliance can provide data protection using Oracle Active Data Guard.

The Oracle Database Appliance is a highly available system in itself. However, a standby database environment can provide data protection and reduces planned and unplanned downtime if the primary database environment becomes unavailable or corrupted. Therefore, a standby database is an integral component of Maximum Availability Architecture (MAA) to provide additional high availability and data protection for any mission-critical production system.With Oracle Maximum Availability Architecture (MAA) Gold Tier best practices, the standby database can be synchronized with the primary database, thereby minimizing database downtime for planned maintenance activities such as database upgrades and unplanned outages such as data corruptions, database failures, cluster failures, power outage, or natural disaster.

The two metrics that need to be considered to develop and implement the appropriate recovery plan are Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Oracle Data Guard is the most comprehensive solution available to eliminate single points of failure for mission-critical Oracle Databases. The MAA Gold Tier prevents data loss (zero RPO) and downtime (zero RTO) in the simplest and most economical manner by maintaining a synchronized physical replica of a production database at a remote location. If the production database is unavailable for any reason, client connections can quickly, and in some configurations transparently, failover to the synchronized replica to restore service.

Oracle Active Data Guard enables administrators to improve performance by offloading processing from the primary database to a physical standby database that is open read-only while it applies updates received from the primary database. Offload capabilities of Oracle Active Data Guard include read-only reporting with the occasional write or update (through DML Re-direct in Oracle Database 19c) and ad-hoc queries (including DML to global temporary tables and unique global or session sequences), data extracts, fast incremental backups, redo transport compression, efficient servicing of multiple remote destinations, and the ability to extend zero data loss protection to a remote standby database without impacting primary database performance.

Oracle Active Data Guard also increases high availability by performing automatic block repair and enabling High Availability Upgrades (utilizing database rolling upgrade automation to bypass the need for downtime while still maintaining a highly available environment). In addition, it includes application continuity which extends data protection to in-flight transactions that may not have been committed. Oracle recommends using a separate, dedicated Oracle Database Appliance system to host the Data Guard standby system for a mission-critical production system running on the primary Oracle Database Appliance system. The MAA best practice is to have a local (synchronous replication) standby database in a nearby data center that has some level of isolation and a remote standby which is routinely maintained through asynchronous replication. This provides protection from disasters which may impact an entire region such as a large scale power outage while still maintaining a RPO of zero in the majority of unplanned outages.

Parent topic: Disaster Recovery on Oracle Database Appliance Using Oracle Data Guard

Benefits of Using Oracle Data Guard and Oracle Active Data Guard

Oracle Data Guard provides numerous benefits and enables greater efficiency and efficacy for the deployed architecture.

Even though Oracle Data Guard itself does provide significant protection, MAA Gold Tier requires Oracle Active Data Guard because without Automatic Block Repair, Application Continuity and DBMS_ROLLING, the RTO/RPO included in Maximum Availability Architecture (MAA) reference architecture cannot be reached.

With the use of Oracle Active Data Guard, the standby database environment does not need to be idle or at dark capacity. Instead, the standby database can actively serve many useful purposes. These additional uses greatly increase the overall return on effort and investment.

Migration to Oracle Database Appliance - If you plan to migrate existing databases to Oracle Database Appliance, then Oracle Data Guard enables an easy approach for migration of your databases to Oracle Database Appliance. You can set up a physical standby database on your Oracle Database Appliance and switch over operations from the legacy environment to the new Oracle Database Appliance environment. This includes migration across certain platforms as well. For example, to migrate your databases currently running on the Windows platform to Oracle Database Appliance, a Linux platform, you can set up Oracle Data Guard between the two environments and perform a switch over. This approach to platform migration provides the flexibility to switchback, if for any reason you choose to do so after testing. Refer to My Oracle Support (MOS) note 413484.1: Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration, for more information about platform migration using Oracle Data Guard.

Note:

Oracle Data Guard also allows you to migrate across database versions using a transient logical standby database.

Disaster Recovery - Oracle Data Guard physical standby database provides an ideal solution for disaster protection. The most common example of a disaster that occurs is a regional power outage, but disaster scenarios vary from burst water or steam pipes, fire, hurricanes, vandalism, to earthquakes, floods, and acts of terrorism. Oracle Data Guard Physical Standby Database maintains a block-for-block copy of the production database. In the event the primary environment becomes unavailable due to any reason, the standby environment can be quickly activated to maintain continued database availability for your applications.

High Availability – Standby database and Oracle RAC can also be useful in maintaining availability during planned and unplanned outages and downtimes. Such events may include configuration changes, hardware replacements, as well as data corruption, failures resulting from human errors, and other unexpected system component or complete system failures.

Standby-First Patching – With Oracle Active Data Guard, the standby database can provide additional protection by first applying any hardware, operating system, Oracle Grid Infrastructure, and qualified database software updates. Validation can occur for hours, days, or even weeks, providing additional assurance before applying the same changes in Oracle RAC rolling manner on the primary database or by issuing an Oracle Data Guard role transition. This additional protection can prevent an outage due to bad patch or high-availability or performance regression due to the patch. The only downtime for the databases is the short period of time required to change roles between primary and standby. For more information, see My Oracle Support (MOS) note 1265700.1: Oracle Patch Assurance - Data Guard Standby-First Patch Apply.

Database Rolling Upgrade – With Active Data Guard and transient logical standby, you can use the standby database to minimize downtime by applying a non-rolling software change such as a major database upgrade on the standby and then subsequently switching over. Downtime is minimized to a couple of seconds due to the Data Guard switchover. For more details, refer to technical briefs: Database Rolling Upgrade using Data Guard and MAA Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING for Oracle databases 12.1 and later.

Auto Block Repair – One of the benefits of the physical standby database is its ability to automatically repair physical block corruptions. In a primary and standby configuration, a corrupt block can be automatically repaired, and this operation can be completely seamless to the application and database administrator. The Block Repair feature is part of the Oracle Active Data Guard option.

Application Continuity (AC) – This feature is available with the Oracle Real Application Clusters (RAC), Oracle RAC One Node and Oracle Active Data Guard options that masks outages from end users and applications by recovering the in-flight database sessions following recoverable outages. It masks outages from end users and applications by recovering the in-flight work for impacted database sessions following outages. Application Continuity performs this recovery beneath the application so that the outage appears to the application as a slightly delayed execution. Application Continuity improves the user experience for both unplanned outages and planned maintenance. It enhances the fault tolerance of systems and applications that use an Oracle database. For an example configuration of Oracle Data Guard with Application Continuity on Oracle Database Appliance, see Configuring Transparent Application Continuity in this publication.

Offloading Workload and Activities – Despite its name, the standby environment does not have to be idle. It can be actively used to maximize the overall return on your investment. With a physical standby database in place, several key activities can be offloaded to the standby environment. These include:

Read-Only Workload – Using Oracle Active Data Guard option, the standby database can be open for read-only query workload while being in the standby mode and accepting redo log updates from the primary database. In many cases, offloading read-only workloads to the standby database can dramatically reduce the production workload, thereby increasing the overall available capacity for the production system.
Backups – Because the Oracle Data Guard physical standby database is a physical copy of the primary database, database backups can be completely offloaded to the standby environment and these backups can be transparently used to restore and recover the primary database in the event of a failure or database loss. Note that if Oracle Active Data Guard option is licensed, then fast incremental backups can be run at the standby database, further adding to the appeal of offloading backups to the standby database.
Snapshot Standby – The Snapshot Standby database is a standby database that can be updated, and provides full data protection for the primary database. It continues to receive redo data from the primary, but the apply process is halted while the standby database is open for read/write operations for testing purposes. When testing is complete, a single command reverts the standby database to its original state, discarding the changes made while it was open in read-write mode and applying the accumulated redo logs to synchronize with the current state of primary database.

Best Practices for Configuring Oracle Data Guard on Oracle Database Appliance

This section describes the best practices for setting up Oracle Data Guard on Oracle Database Appliance.

Oracle Database Appliance Bare Metal and DB Systems Configurations

Oracle Database Appliance can be configured as a bare metal platform with KVM and DB system support. Integrated Data Guard configuration with ODACLI is the preferred way on bare metal and DB system deployments. However, the manual Oracle Data Guard physical standby setup process outlined in this technical brief can be used on both Oracle Database Appliance bare metal systems and DB systems.

Oracle Real Application Clusters (Oracle RAC) and Oracle Data Guard are fundamental and essential components of Oracle Maximum Availability Architecture (MAA). While you can also setup Oracle Data Guard configuration between Oracle Database Appliance X7-2 S|M, X8-2 S|M, X9-2 S|L, X-10 S|L, X9-2-HA, and X10-HA hardware models (the smaller, single-node configurations), such configurations do not adhere to MAA guidelines because Oracle Real Application Clusters (Oracle RAC) runs only on Oracle Database Appliance high-availability hardware models (X7-2 HA, X8-2 HA, X9-2-HA, and X10-HA).

Oracle Data Guard enables you to instantly deploy an effective disaster recovery protection strategy right from the initial deployment of your Oracle Database Appliance. You can use the Oracle Data Guard Physical Standby environment for multiple purposes besides a disaster recovery solution. The physical standby configuration and setup process outlined in this technical brief is quick, simple, and it can be completed without any downtime incurred on the primary database. Most of the standby creation steps are automated using tools such as odacli, Oracle RMAN, and Oracle Data Guard Broker.

For a complete list of general Oracle Data Guard best practices, which also apply to the Oracle Database Appliance environment, refer to Oracle Maximum Availability Architecture and Oracle Data Guard best practices available at https://www.oracle.com/database/technologies/high-availability/oracle-database-maa-best-practices.html.

Upgrade to the latest Oracle Database Appliance release – Functionality can change with Oracle releases, such as syncing up the database related metadata. Backups and some other features might not work through Oracle Database Appliance tooling without up-to-date metadata for standby databases. With Oracle Database Appliance release 19.8 and later, Oracle Data Guard is integrated with Oracle Database Appliance. You can use ODACLI commands to quickly set up and manage Oracle Data Guard with another Oracle Database Appliance.

Match the primary and standby database configuration – To maintain consistent service levels and to use the primary and standby databases transparently, it is important to match the resources, setup, and configuration of the primary and standby systems. Significant differences between the primary and standby database configuration can result in sub-optimal performance and unpredictable behavior when role transitions occur. Specifically, the following recommendations must be considered:

Run primary and standby database on separate Oracle Database Appliances – It is recommended that the primary and the standby databases run on separate, dedicated Oracle Database Appliance units preferably located in a geographically distant location.
Run primary and standby database with the same configuration – Three different database configurations are supported on Oracle Database Appliance; Oracle RAC database, Oracle RAC One, and Single-Instance Enterprise Edition database. The standby database should also be of the same configuration type as the primary database. Thus, if the primary database is configured as an Oracle RAC database, then the standby database should also be configured as an Oracle RAC database.
Keep symmetry between the primary and standby sites – The instances on the primary and standby databases should be configured similar to each other in terms of database parameter settings including memory, CPU, networking, and storage. This helps avoid any unpredictability when the database switch roles. In addition, any operating system configuration customizations should be mirrored in the two environments.
Configure flashback database on both primary and standby databases – The Flashback Database feature enables rapid role transitions and reduces the effort required to re-establish database roles after a transition. As a best practice, flashback database must be configured on both primary and the standby databases. If FLASHBACK is only deemed necessary for re-instantiation, then it would be a good practice to reduce the retention time from the default 24 hours to 2 hours. It should be noted that as of the Oracle Database 19c release, all restoration points are automatically propagated to standby databases. The Oracle Integrated Data Guard feature configures flashback database automatically.
Use dedicated network for standby traffic – Oracle Database Appliance comes pre-built with multiple redundant network interfaces. If required, a separate network path can be configured for the standby traffic to minimize any performance impact on the user and application-related workload. Note that since Oracle Data Guard needs to transport only the changes made to the primary database from the primary database to the standby database, it does not impose any unnecessary requirements on the network than is needed. Therefore, many deployments of Oracle Data Guard may not require a separate network path for redo log transport between primary and standby. However, some high volume applications or your organization’s best practices and standards may require a separate network path for redo log transport. Oracle Database Appliance does provide additional network interfaces on each server node that can be used for this purpose. Refer to the documentation for additional details on configuring a dedicated network for disaster recovery purposes on Oracle Database Appliance.
Utilize Oracle Active Data Guard – Oracle Active Data Guard allows for read-only standby of near current data since redo apply remain continuously active between primary and standby environments. This can help distribute or offload the read-only workload from the primary environment to the standby database, increasing the return on investment in the standby database. Note that with Oracle Active Data Guard, fast incremental backups can be run on the standby database. The fast incremental backups could potentially reduce backup windows from hours to minutes. Rolling upgrades can also be done using the standby database, reducing downtime to near-zero. Additionally, Active Data Guard with real time apply enables bi-directional auto-block corruption repair providing another layer of data protection for mission-critical applications.
Use Oracle Data Guard Broker – Oracle Data Guard Broker's interfaces improve usability and centralize management and monitoring of an Oracle Data Guard configuration. It minimizes overall management, and it has inherent checks and balances for Oracle Data Guard configuration.
Setup Oracle Clusterware role-based services – Refer to Client Failover Best Practices for Highly Available Oracle Databases.

See the topic Oracle Database Appliance References in this document for additional references.

Parent topic: Disaster Recovery on Oracle Database Appliance Using Oracle Data Guard