Before setting up Data Guard ensure that your Exadata Cloud Infrastructure environment meets the following network requirements:

• The primary and standby databases can be part of VM clusters in different compartments.
• 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. Networking is configured on the cloud VM cluster resource for systems using the The new Exadata Resource Model, and on the DB system resource for system using the old resource model. See Remote VCN Peering using an RPC .

  For Exadata Data Guard configurations, OCI supports the use of hub-and-spoke network topology for the VCNs within each region. This means that the primary and standby databases can each utilize a "spoke" VCN that passes network traffic to the "hub" VCN that has a remote peering connection. See Transit Routing inside a hub VCN for information on setting up this network topology.

• To set up Oracle Data Guard within a single region, both Exadata Cloud Infrastructure instances must use the same VCN. When setting up Data Guard within the same region, Oracle recommends that the instance containing the standby database be in a different availability domain from the instance containing the primary database to improve availability and disaster recovery.

• Configure the ingress and egress security rules for the subnets of both Exadata Cloud Infrastructure instances 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 Exadata Cloud Infrastructure instance uses the source CIDR 10.0.0.0/24 and the subnet of the standby instance uses the source CIDR 10.0.1.0/24, then create rules as shown in the subsequent example.

Security Rules for Subnet of Primary Exadata Cloud Infrastructure instance

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

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 Exadata Cloud Infrastructure instance

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

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 .

To change the SYS password or rotate TDE keys, use OCI API.

Possible TDE key replication issue, and MRP and DG LCM operation failures.

KMS RPM libkmstdepkcs11_1.286-1.286-1-Linux.rpm is the latest available which supports active replication of key between cross-region KMS vaults (source and target), and it is recommended to upgrade the RPM on clusters participating in Data Guard. OCI Vault cross-region Data Guard works with a lower version of RPM, but the older version does not guarantee active replication of keys. If the TDE keys have any replication issue between vaults, Data Guard replication might have an impact (MRP fails on standby cluster due to missing key on target vault) and MRP could resume only after the keys are replicated to the target vault. To avoid MRP and DG LCM operation failures, upgrade the libkms RPM on both the clusters, and restart the databases (only databases using customer-managed keys).

When adding a node to a VM cluster, an instance of the Data Guard database is automatically created on the new node. However, metadata updation on the remote database, that is, the primary database if addition is done on the standby database and vice versa, must be done manually.

This can be done by copying over the addinstance JSON file, /var/opt/oracle/dbaas_acfs/<dbname>/addInstance.json created at the end of instance addition and running the /var/opt/oracle/ocde/rops update_instance <dbname> <path to addInstance JSON> command on any node of the remote cluster.

When removing a node from a VM cluster, the instance and it's metadata on the removing node is deleted automatically. However, deletion of the corresponding metadata on the remote database, that is, the primary database if removal is done on the standby database and vice versa, must be done manually.

This can be done by running the /var/opt/oracle/ocde/rops remove_instance <dbname> <Instance Name> command on any node of the remote cluster.

A switchover reverses the primary and standby database roles.

Each database continues to be part of the Data Guard group in its new role. A switchover ensures no data loss. You can use a switchover before you perform planned maintenance on the primary database. Performing planned maintenance on an Exadata database virtual machine with a Data Guard group is typically done by switching the primary to the standby role, performing maintenance on the standby, and then switching it back to the primary role.

A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable.

The failover may or may not result in data loss depending upon the protection mode and whether your primary and target standby databases were synchronized at the time of the primary database failure. For more information refer to Manual Failover in the Data Guard documentation.

Reinstates a database into the standby role in a Data Guard group.

You can use the reinstate command to return a failed database into service after correcting the cause of failure.

Learn to set up Data Guard group between databases.

1. Open the navigation menu. Under Oracle Database, click Oracle Exadata Database Service on Dedicated Infrastructure.
2. Choose your Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable Oracle Data Guard..
3. Navigate to the cloud VM cluster or DB system that contains a database you want to assume the primary role:
   • Cloud VM clusters ( new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.
   • DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.
4. On the VM cluster or DB system details page, in the Databases section, click the name of the database you want to make primary.
5. On the Database Details page, under Resources, click Data Guard Associations.
6. Click Add standby.
7. On the Add standby page, configure your Data Guard group.
   • In the Select peer DB system section, provide the following information for the standby database to obtain a list of available Exadata systems in which to locate the standby database:
     • Region: Select a region where you want to locate the standby database. The region where the primary database is located is selected, by default. You can choose to locate the standby database in a different region. The hint text associated with this field tells you in which region the primary database is located.
     • Availability domain: Select an availability domain for the standby database. The hint text associated with this field tells you in which availability domain the primary database is located.
     • Shape: Select the shape of the standby Exadata system.
     • Data Guard peer resource type: Select DB System or VM Cluster.
     • Select a DB system or cloud VM cluster from the drop-down list.
   • Choose the Data Guard experience:
     • Use the new Data Guard group Resource With this option, your new Data Guard configuration will be created as a Data Guard group resource. This option with new APIs supports adding multiple standby databases and provides other enhancements. If you currently have automation that manages Data Guard operations using the existing Data Guard Association API, you can update your applications to use the new API to take advantage of these new capabilities.
     • Use the existing Data Guard Association Resource Choose this option if your automation for managing Data Guard operations relies on the existing Data Guard Association API. However, you will not be able to add multiple standby databases and will not get the enhancements provided by the new API.
   • Data Guard group details:
     • Data Guard Type: Select Active Data Guard or Data Guard. Active Data Guard provides additional features including: Real-Time Query and DML Offload, Automatic Block Repair, Standby Block Change Tracking, Far Sync, Global Data Services, and Application Continuity. Note that Active Data Guard requires an Oracle Active Data Guard license. For more information on Active Data Guard, see Active Data Guard. For a complete overview of both Data Guard types, see Introduction to Oracle Data Guard
     • Protection mode: The protection mode can be Maximum Performance or Maximum Availability. See Oracle Data Guard Protection Modes for information on these options.
     • Transport type: The redo transport type used for this Data Guard group. See Redo Transport Servicesfor information on these options.

       Protection Mode and Transport Type: Rules for Standby Database Creation

       • Creating the first standby: You cannot modify the Protection Mode or Transport Type for the first standby database during its creation. It is possible to modify it later.
         • The default settings are:
           • Protection Mode: Max Performance
           • Transport Type: Async
       • Creating the second to Nth standby: You cannot modify the Protection Mode or Transport Type for any subsequent standby databases.
         • The Protection Mode is inherited from the first standby.
         • The default Transport Type is set to Async.
   • In the Choose Database Home section, choose one of the following:
     • Select an existing Database Home: If you use this option, select a home from the Database Home display name drop-down list.
     • Create a new Database Home: If you choose this option, enter a name for the new Database Home in the Database Home display name field. Click Change Database Image to select a database software image for the new Database Home. In the Select a Database Software Image panel, do the following:
       1. Select the compartment containing the database software image you want to use to create the new Database Home.
       2. Select the region containing the database software image you want to use to create the new Database Home. Region filter defaults to the currently connected region and lists all the software images created in that region. When you choose a different region, the software image list is refreshed to display the software images created in the selected region.
       3. Select the Oracle Database software version that the new Database Home will use, then choose an image from the list of available images for your selected software version.
       4. Click Select.
       Note
       
       

       • Oracle recommends applying the same list of patches to the Database Homes of the primary and standby databases.
       • If you are using the new Data Guard group resource, you must first create the database home before adding the standby database.
   • In the Configure standby database: section, provide standby database details.
     Note
     
     You cannot modify the db_unique_name and SID prefix after creating the database.
     • Database unique name: Optionally, specify a value for the DB_UNIQUE_NAME database parameter. This value must be unique across the primary and standby cloud VM clusters. The unique name must meet the requirements:
       • Maximum of 30 characters
       • Contain only alphanumeric or underscore (_) characters
       • Begin with an alphabetic character
       • Unique across the VM cluster. Recommended to be unique across the tenancy.
       If not specified, the system automatically generates a unique name value, as follows:

       <db_name>_<3_chars_unique_string>_<region-name>

     • Database password: Enter the database administrator password of the primary database. Use this same database administrator password for the standby database.

       Note
       
       The administrator password and the TDE wallet password must be identical. If the passwords are not identical, then follow the instructions in Changing the Database Passwords to ensure that they are.
     • TDE wallet password: Enter the TDE wallet password.
8. Click Show advanced Options to specify advanced options for the standby database:

   • Management:

     Oracle SID prefix: The Oracle Database instance number is automatically added to the SID prefix to create the INSTANCE_NAME database parameter. The INSTANCE_NAME parameter is also known as the SID. If not provided, then the SID prefix defaults to the first 12 characters of the db_unique_name.

     Note
     
     Entering an SID prefix is only available for Oracle 12.1 databases and above.

     The SID prefix must meet the requirements:

     • Maximum of 12 characters
     • Contain only alphanumeric characters
     • Begin with an alphabetic character
     • Unique in the VM cluster and across primary and standby databases
9. Click Add standby. When you create the association, the details for a database and its peer display their respective roles as Primary or Standby.

To view the role of each database in a Data Guard group in an Cloud VM Cluster, follow this procedure.

1. Open the navigation menu. Under Oracle Database, click Oracle Exadata Database Service on Dedicated Infrastructure.
2. Choose your Compartment.
3. Navigate to the cloud VM cluster that contains the databases you wish to view their roles in Data Guard associations.
4. In the Databases section under Resources, the role of each database in this VM Cluster is indicated in the Data Guard role column.

Learn to enable automatic backups on a standby database.

1. Open the navigation menu. Under Oracle Database, click Oracle Exadata Database Service on Dedicated Infrastructure.
2. Choose your Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable automatic database.
3. Navigate to the cloud VM cluster or DB system that contains the primary database.

   • Cloud VM clusters ( new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   • DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. On the VM cluster or DB system details page, in the Databases section, click the name of the primary database.
5. On the Database Details page, under Resources, click Data Guard group.
6. Click the name of the standby database for which you want to enable automatic backups.

   The system displays a banner if automatic backups are not enabled for this database.

7. Click Enable automatic backups on the banner.
8. On the resulting Configure Automatic Backups window, enter the following details:
   • Enable automatic backup: Check the check box to enable or disable automatic incremental backups for this database.
     Note
     
     

     • If your database is in a security zone compartment, you must enable automatic backups.
     • If you are enabling automatic backups, you can select to configure Recovery Service or Object Storage as the Backup destination. However, if the backup was already configured on the primary database, then the standby must use the same backup destination.
   • If Recovery Service is selected as the Backup destination, you can configure the following options:
     • Protection policy: You can select from one of the preset protection policies or a custom policy. The system automatically deletes your backups at the end of your chosen protection policy recovery window.
     • Real-time data protection: Real-time protection is the continuous transfer of redo changes from a protected database to Recovery Service. This reduces data loss and provides a recovery point objective (RPO) near 0. This is an extra cost option.
     • Deletion options after database termination: You can use the following options to retain managed database backups after the database is terminated. These options can also help restore the database from backups in case of accidental or malicious damage to the database.
       • Retain backups according to the retention period: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be removed at the end of the specified retention period.
       • Retain backups for 72 hours, then delete: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be retained for 72 hours and then deleted. The backups are retained for 72 hours to safeguard against accidental deletion by the user.
     • Scheduled day for initial backup: Select a day of the week for the initial backup to begin.
     • Scheduled time for initial backup (UTC): Select a time for the initial backup to begin. The initial backup could start at any time or within the chosen two-hour scheduling window.
     • Scheduled time for daily backup (UTC): Select a time for the daily backup to begin. The daily backup could start at any time or within the chosen two-hour scheduling window.
     • Take the first backup immediately: A full backup is an operating system backup of all data files and the control file that constitute an Oracle Database. A full backup must also include the parameter files associated with the database. You can take a database backup when the database is shut down or while the database is open. You must not typically take a backup after an instance failure or other unusual circumstances. If you select to defer the initial backup, your database may not be recoverable in the event of a database failure.
   • If Object Storage is selected as the Backup destination, you can configure the following options:
     • Backup retention period: If you select to enable automatic backups, you can select a policy with one of the preset retention periods. The system automatically deletes your incremental backups at the end of your chosen retention period. You can change the backup retention period after provisioning.
     • Deletion options after database termination: You can use the following options to retain managed database backups after the database is terminated. These options can also help restore the database from backups in case of accidental or malicious damage to the database.
       • Retain backups according to the retention period: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be removed at the end of the specified retention period.
       • Retain backups for 72 hours, then delete: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be retained for 72 hours and then deleted. The backups are retained for 72 hours to safeguard against accidental deletion by the user.
     • Scheduled day for full backup: Select a day of the week for the initial and future full backups to begin.
     • Scheduled time for full backup (UTC): Select a time for the full backup to begin. The full backup could start at any time or within the chosen two-hour scheduling window.
     • Scheduled time for incremental backup (UTC): Select a time for the incremental backup to begin. The incremental backup could start at any time or within the chosen two-hour scheduling window.
     • Take the first backup immediately: A full backup is an operating system backup of all data files and the control file that constitute an Oracle Database. A full backup must also include the parameter files associated with the database. You can take a database backup when the database is shut down or while the database is open. You must not typically take a backup after an instance failure or other unusual circumstances. If you select to defer the initial backup, your database may not be recoverable in the event of a database failure.
9. Click Save Changes.

You can initiate a switchover operation on a standby database that is a member of the Data Guard group.

1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
2. Choose the Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable Oracle Data Guard.

3. Navigate to the cloud VM cluster or DB system that contains the Data Guard association:

   Cloud VM clusters (new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. Under Resources, click Data Guard group.
5. Select the standby database in the Data Guard group on which you want to perform a switchover. Click the Actions icon (three dots), and then click Switchover.

6. In the Switchover database dialog box, enter the database admin password, and then click Switchover.

   This database should now assume the role of the standby, and the standby should assume the role of the primary in the Data Guard group.

1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
2. Choose the Compartment that contains the Exadata Cloud Service instance with the database for which you want to enable Oracle Data Guard.
3. Navigate to the cloud VM cluster or DB system that contains the Data Guard association:

   Cloud VM clusters ( new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. Under Resources, click Data Guard group.

   A list of databases that are members of the Data Guard group is displayed with the Data Guard type you have chosen for each Data Guard group member.

5. To edit Data Guard group details, click the Actions icon (three dots), and then click Edit.
6. In the Edit Data Guard group panel, configure the Data Guard group:
   • Data Guard Type: Select Active Data Guard or Data Guard. Active Data Guard provides additional features including: Real-Time Query and DML Offload, Automatic Block Repair, Standby Block Change Tracking, Global Data Services, and Application Continuity. Note that Active Data Guard requires an Oracle Active Data Guard license. For more information on Active Data Guard, see Active Data Guard. For a complete overview of both Data Guard types, see Introduction to Oracle Data Guard
   • Protection mode: The protection mode can be Maximum Performance or Maximum Availability. See Oracle Data Guard Protection Modes for information on these options.

   • Transport type: The redo transport type used for this Oracle Data Guard group.

   • Database admin password: Enter the ADMIN password for the database.
7. Click Save.

You can initiate a failover operation on a standby database that is a member of the Data Guard group.

1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
2. Choose the Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable Oracle Data Guard.
3. Navigate to the cloud VM cluster or DB system that contains the Data Guard association:

   Cloud VM clusters ( new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. Under Resources, click Data Guard group.
5. Select the standby database in the Data Guard group on which you want to perform a failover. Click the Actions icon (three dots), and then click Failover.
6. In the Failover database dialog box, enter the database admin password, and then click Failover.
   Note
   
   You can initiate a failover even if the primary database is in a healthy state; however, exercise caution when performing a failover.

   This database should now assume the role of the primary, and the old primary's role should display as Disabled Standby.

After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby. After you correct the cause of failure, you can reinstate the failed database as a functioning standby for the current primary.

1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
2. Choose the Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable Oracle Data Guard.
3. Navigate to the cloud VM cluster or DB system that contains the Data Guard association:

   Cloud VM clusters (new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. Under Resources, click Data Guard group.
5. For the Data Guard group on which you want to reinstate this database, click the Actions icon (three dots), and then click Reinstate.

6. In the Reinstate database dialog box, enter the database admin password, and then click Reinstate.

   This database should now be reinstated as the standby in the Data Guard group.

On an Exadata Cloud Infrastructure instance, you remove a Data Guard group by terminating all the standby database.

1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure.
2. Choose the Compartment that contains the Exadata Cloud Infrastructure instance with the database for which you want to enable Oracle Data Guard.

3. Navigate to the cloud VM cluster or DB system that contains the standby database:

   Cloud VM clusters (new resource model): Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

   DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

4. For the standby database you want to terminate, click the Actions icon (three dots), and then click Terminate.

5. In the Terminate database dialog box, enter the name of the database, and then click OK.