Using Oracle Data Guard with Exadata DB Systems

Note

This procedure is only applicable to Exadata DB systems. To use Oracle Data Guard with bare metal and virtual machine DB systems, see Using Oracle Data Guard.

This topic explains how to use the Console or the API to manage Oracle Data Guard associations in your Exadata DB system. When you use the Console or the API to enable Oracle Data Guard for an Oracle Cloud Infrastructure Exadata DB system database:

  • The standby database is a physical standby.
  • The peer databases (primary and standby) are:

    • in the same compartment
    • both Exadata DB system shapes
    • identical database versions
  • You are limited to one standby database for each primary database.

To configure an Oracle Data Guard system between on-premises and Oracle Cloud Infrastructure DB systems, or to configure your database with multiple standbys, you must access the database host directly and set up Oracle Data Guard manually.

For complete information on Oracle Data Guard, see the Data Guard Concepts and Administration documentation on the Oracle Document Portal.

Required IAM Service Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a policy  written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which compartment  you should work in.

If you are new to policies, see Getting Started with Policies and Common Policies.

Prerequisites

An Exadata DB system Oracle Data Guard implementation requires two Exadata DB systems: one containing the primary database and one containing the standby database. When you enable Oracle Data Guard for an Exadata DB system database, the DB system with the database to be used as the standby must already exist before you enable Oracle Data Guard.

Network Requirements

Ensure that your environment meets the following network requirements:

  • If you want to configure Oracle Data Guard across regions, then you must configure remote virtual cloud network (VCN) peering between the primary and standby databases. See Remote VCN Peering (Across Regions).
  • To set up Oracle Data Guard within a single region, both DB systems must use the same VCN. When setting up Data Guard within the same region, Oracle recommends that the DB system of the standby database be in a different availability domain  from the DB system of the primary database to improve availability and disaster recovery.
  • Configure the ingress and egress security rules for the subnets of both DB systems in the Oracle Data Guard association to enable TCP traffic to move between the applicable ports. Ensure that the rules you create are stateful (the default).

    For example, if the subnet of the primary DB System uses the source CIDR 10.0.0.0/24 and the subnet of the standby DB system uses the source CIDR 10.0.1.0/24, then create rules as shown in the subsequent example.

    Note

    The egress rules in the example show how to enable TCP traffic only for port 1521, which is a minimum requirement for Oracle Data Guard to work. If TCP traffic is already enabled for all destinations (0.0.0.0/0) on all of your outgoing ports, then you need not explicitly add these specific egress rules.

    Security Rules for Subnet of Primary DB System

    Ingress Rules:
    
    						Stateless: No
    						Source: 10.0.1.0/24 
    						IP Protocol: TCP 
    						Source Port Range: All 
    						Destination Port Range: 1521
    						Allows: TCP traffic for ports: 1521
    
    						Egress Rules:
    
    
    						Stateless: No
    						Destination: 10.0.1.0/24 
    						IP Protocol: TCP 
    						Source Port Range: All
    						Destination Port Range: 1521
    						Allows: TCP traffic for ports: 1521
    					

    Security Rules for Subnet of Standby DB System

    Ingress Rules:
    
    						Stateless: No
    						Source: 10.0.0.0/24 
    						IP Protocol: TCP 
    						Source Port Range: All 
    						Destination Port Range: 1521
    						Allows: TCP traffic for ports: 1521
    
    						Egress Rules:
    
    						Stateless: No
    						Destination: 10.0.0.0/24 
    						IP Protocol: TCP 
    						Source Port Range: All
    						Destination Port Range: 1521
    						Allows: TCP traffic for ports: 1521
    					

    For information about creating and editing rules, see Security Lists.

Password Requirements

For Oracle Data Guard operations to work, the SYS password and the TDE wallet password of the primary and standby databases must all be the same. If you change any one of these passwords, then you must update the rest of the passwords to match. See Changing the Database Passwords to learn how to change the SYS password or the TDE wallet password.

If you make any change to the TDE wallet (such as adding a master key for a new PDB or changing the wallet password), then you must copy the wallet from the primary database to the standby database so that Oracle Data Guard can continue to operate. For Oracle Database versions prior to Oracle Database 12c release 2 (12.2), if you change the SYS password on one of the peers, then you must manually sync the password file between the DB systems.

Working with Oracle Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. The Oracle Cloud Infrastructure Database Data Guard implementation requires two databases: one in a primary role and one in a standby role. The two databases compose an Oracle Data Guard association. Most of your applications access the primary database. The standby database is a transactionally consistent copy of the primary database.

Oracle Data Guard maintains the standby database by transmitting and applying redo data from the primary database. If the primary database becomes unavailable, then you can use Oracle Data Guard to switch or failover the standby database to the primary role.

Switchover

A switchover reverses the primary and standby database roles. Each database continues to participate in the Oracle Data Guard association in its new role. A switchover ensures no data loss. Performing planned maintenance on a DB system with an Oracle Data Guard association is typically done by switching the primary database to the standby role, performing maintenance on the standby database, and then switching the standby database back to the primary role.

Failover

A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable. A failover might result in some data loss when you use Maximum Performance protection mode.

Reinstate

Reinstates a database into the standby role in an Oracle Data Guard association. You can use the reinstate command to return a failed database into service after correcting the cause of failure.

Note

You cannot terminate a primary database that has an Oracle Data Guard association with a peer (standby) database. Delete the standby database first. Alternatively, you can switch over the primary database to the standby role, and then terminate it.

You cannot terminate an Exadata DB system that includes Oracle Data Guard-enabled databases. You must first remove the Oracle Data Guard association by terminating the standby database.

Using the Console

Use the Console to enable an Oracle Data Guard association between databases, change the role of a database in an Oracle Data Guard association using either a switchover or a failover operation, and reinstate a failed database.

When you enable Oracle Data Guard, a separate Oracle Data Guard association is created for the primary and the standby database.

To enable Oracle Data Guard on an Exadata DB system
To perform a database switchover
To perform a database failover
To reinstate a database
To terminate a Data Guard association on an Exadata DB system

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage Data Guard associations on an Exadata DB system:

For the complete list of APIs for the Database service, see Database Service API.