Oracle Cloud Infrastructure Documentation

Use Oracle Data Guard with Exadata Cloud Infrastructure

Learn to configure and manage Data Guard Groups in your VM cluster.

Parent topic: How-to Guides

About Using Oracle Data Guard with Exadata Cloud Infrastructure

Oracle 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.

Oracle Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Oracle Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability. Oracle Data Guard transport services are also used by other Oracle features such as Oracle Streams and Oracle GoldenGate for efficient and reliable transmission of redo from a source database to one or more remote destinations.

For complete information on Oracle Data Guard, see the Oracle Data Guard Concepts and Administration documentation and Oracle Data Guard Broker Concepts on the Oracle Database Documentation portal.

This topic explains how to use the Console or the API to configure and manage Data Guard resources in your VM cluster.

When you use the Console or the API to enable Data Guard for an Exadata database compute node database:

  • The standby database that is created is a physical standby.
  • The versions of peer databases (primary and standby) are identical.
  • The standby database is deployed as an open, read-only database (Active Data Guard).
  • A primary database can support up to a maximum of six standby databases.

Prerequisites for Using Oracle Data Guard with Exadata Cloud Infrastructure

An Exadata Cloud Infrastructure Oracle Data Guard implementation requires two existing Exadata VM Clusters: one containing an existing database that is to be duplicated by Data Guard, and one that will house the new standby database by Data Guard.

Note

Oracle strongly recommends the primary and standby databases for any production workloads be on different Exadata Cloud Infrastructures for better fault isolation and disaster protection. If you are adding a new standby in the same region with multiple availability domains, Oracle recommends choosing a separate availability domain for complete availability domain or data center fault isolation. If you are adding a new standby across regions, the standby will have fault isolation for a regional failure as well.

When enabling Data Guard, you must create a new Database Home on the standby instance to host the new standby database. Alternatively, you can provision the standby database within an existing Database Home on the standby instance. For information on creating the required resources for the standby system, see the following topics:

You can use a custom database software image to that contains the necessary patches for your databases when creating a Database Home on either the primary or the standby Exadata instance. See Oracle Database Software Images for information on working with custom Oracle Database software images.

If you choose to provision a standby database in an existing Database Home, ensure that the target Database Home on the standby instance has all required patches that are in use for the primary database before you provision the standby database. See the following topic for more information on patching an existing Database Home:

If you are creating a Data Guard Group and you are using customer managed keys to encrypt the database, you must have configured the Vault Service and created a master key. See To administer Vault encryption keys and Key and Secret Management Concepts.

Related Topics

Parent topic: Use Oracle Data Guard with Exadata Cloud Infrastructure

Network Requirements for Data Guard

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. 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.

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

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

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

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

Known Issues for Exadata Cloud Infrastructure and Data Guard

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).

Adding a Node to a VM Cluster

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.

Removing a Node from a VM 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.

Working with Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.

The primary and standby databases constitute a Data Guard Group. Most of your applications access the primary database. A standby database is a transactionally consistent copy of the primary database.

Data Guard maintains the standby database by transmitting and applying redo data from the primary database. If the primary database becomes unavailable, you can use Data Guard to switchover or failover the standby database to the primary role. This is true even if you have more than one standby database.

  • Switchover
    A switchover reverses the primary and standby database roles.
  • Failover
    A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable.
  • Reinstate
    Reinstates a database into the standby role in a Data Guard Group.

Parent topic: Use Oracle Data Guard with Exadata Cloud Infrastructure

Switchover

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.

Parent topic: Working with Data Guard

Failover

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.

Parent topic: Working with Data Guard

Reinstate

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.

Note

You cannot terminate a primary database that is part of a Data Guard Group that contains one or more standby databases. You will have to terminate the standby databases first. Alternatively, you can switch over the primary database to the standby role, and then terminate the former primary.

You cannot terminate a VM cluster that includes Data Guard enabled databases. You must first terminate the standby databases that are part of the Data Guard Group.

Parent topic: Working with Data Guard

Support for Concurrent Data Guard Operations in Multiple Standby Environments

In addition to the Enhancements to support concurrent Data Guard, Container Database (CDB), and Pluggable Database (PDB) Operations, these enhancements enable you to perform concurrent operations on CDBs and PDBs alongside Data Guard migration operations in environments with multiple standby databases.

You can now perform the following operations in parallel within the same Oracle Home:

  • Perform Add Standby operations concurrently on different databases.
  • Create or delete a CDB while an Add Standby operation is running on another database, and vice versa.
  • Create or delete a PDB while an Add Standby operation is running on another database, and vice versa.
  • Performing Data Guard actions (switchover, failover, reinstate, convert to snapshot and convert to physical) while an Add Standby operation is running on another database, and vice versa.

Similarly, you can perform the following Migrate Data Guard operations in parallel:

  • Perform migrate Data Guard operations concurrently on different databases.
  • Perform migrate Data Guard operations while an Add Standby operation is running on another database, and vice versa.
  • Create or delete a CDB while a migrate Data Guard operations is running on another database, and vice versa.
  • Create or delete a PDB while a migrate Data Guard operations is running on another database, and vice versa.
  • Performing Data Guard actions (switchover, failover, reinstate, convert to snapshot and convert to physical) while a migrate Data Guard operations is running on another database, and vice versa.

Enhanced Data Guard Health Status Reporting

The enhanced Data Guard health status reporting provides comprehensive insights into protection mode, switchover and failover readiness, and data loss exposure across primary and standby databases.

With clear visual indicators (green, yellow, red, gray), you can quickly assess the readiness of your databases for role transitions and failover events. Additionally, detailed redo transport lag metrics help you evaluate potential data loss scenarios, enabling proactive disaster recovery planning and improved operational reliability.

Protection Mode

Data Guard associations provide two protection modes:

  • Maximum Availability – Enables zero data loss failover and uses synchronous redo transport to at least one standby database.
  • Maximum Performance – Enables near-zero data loss failover with no performance impact by using asynchronous transport to all standby targets.

Switchover Readiness

  • Primary Database: status indicators – Green, Yellow, Red, Gray.
    • Green (Healthy): All standby databases have passed all switchover readiness checks.
    • Yellow (Warning): Applicable only if the primary database has multiple standby databases. A subset of standby databases is switchover-ready. Address the failed checks.
    • Red (Critical): None of the standby databases are switchover-ready. Address failed checks to avoid extended downtime.
    • Gray (Unknown): Shown when the health status cannot be determined at that point.
  • Standby Database: status indicators – Green, Red, Gray.
    • Green (Healthy): The standby database has passed all switchover readiness checks.
    • Red (Critical): This standby database is not switchover-ready. Address failed checks to avoid extended downtime during switchover attempts.
    • Gray (Unknown): Shown when the health status cannot be determined at that point.
  • Disabled Standby Database and Snapshot Standby Database: status indicators – Gray
    • Gray (Unknown): Disabled standby databases always appear as Unknown because their health status cannot be determined.

Failover Readiness

  • Primary Database: status indicators – Green, Yellow, Red, Gray.
    • Green (Healthy): All standby databases have passed all failover readiness checks.
    • Yellow (Warning): Applicable only if the primary database has multiple standby databases. A subset of standby databases is failover-ready. Address the failed checks.
    • Red (Critical): None of the standby databases are failover-ready. Address failed checks to avoid extended downtime.
    • Gray (Unknown): Shown when the health status cannot be determined at that point.
  • Standby Database and Snapshot Standby: status indicators – Green, Red, Gray.
    • Green (Healthy): The standby database has passed all failover readiness checks.
    • Red (Critical): This standby database is not failover-ready. Address failed checks to avoid extended downtime during failover.
    • Gray (Unknown): Shown when the health status cannot be determined at that point.
  • Disabled Standby Database: status indicators – Gray
    • Gray (Unknown): Disabled standby databases always appear as Unknown because their health status cannot be determined.
Note

When the health status cannot be determined for any database in a Data Guard Group at a given point in time, the status appears as null in the SDK/CLI, and Terraform, and as UNKNOWN (gray icon) in the Console.

Data Loss Exposure

  • Primary Database: Data loss exposure is defined as the redo transport lag between the primary and standby databases. "Last Computed" if displayed represents the last time the metric could be retrieved and calculated.
  • Standby Database: Data loss exposure is defined as the redo transport lag between the primary and standby databases. "Last Computed" if displayed represents the last time the metric could be retrieved and calculated.

Refresh Data Guard health status

Run an explicit refresh to get the latest status.

Using the Console to Manage an Oracle Data Guard Group

Learn how to enable a Data Guard Group between databases, change the role of a database in a Data Guard Group using either a switchover or a failover operation, and reinstate a failed database.

When you enable Data Guard, a separate Data Guard Group is created between the primary and the standby databases.

Parent topic: Use Oracle Data Guard with Exadata Cloud Infrastructure

To view Data Guard Group details of databases in a Cloud VM Cluster

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 AI 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.
    • The role of each database in this VM Cluster is indicated in the Data Guard role column.
    • The service on which each database is running is indicated in the Service name column.

To enable automatic backups on a standby database

Learn to enable automatic backups on a standby database.

  1. Open the navigation menu. Under Oracle AI 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 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.

  4. On the VM cluster 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:
      Note

      To use Autonomous Recovery Service as a backup destination, the Oracle Database version must be 19.18 or later.

      • 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.

To perform a database switchover

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 AI 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 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.

  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.

Note

You can now:
  • Perform Data Guard actions (switchover, failover, and reinstate) while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
  • Perform Data Guard setup concurrently on different databases within the same Oracle home.
  • Perform Data Guard actions (switchover, failover, and reinstate) concurrently on different databases within the same Oracle home.
  • Perform Data Guard setup while simultaneously updating VM Cluster tags.
  • Create or delete a PDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.

To edit the Oracle Data Guard Group details

  1. Open the navigation menu. Click Oracle AI 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 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.

  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.

To perform a database failover

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 AI 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 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.

  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.

Note

You can now:
  • Perform Data Guard actions (switchover, failover, and reinstate) while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
  • Perform Data Guard setup concurrently on different databases within the same Oracle home.
  • Perform Data Guard actions (switchover, failover, and reinstate) concurrently on different databases within the same Oracle home.
  • Perform Data Guard setup while simultaneously updating VM Cluster tags.
  • Create or delete a PDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.

To reinstate a database

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 AI 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 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.

  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.

Note

You can now:
  • Perform Data Guard actions (switchover, failover, and reinstate) while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
  • Perform Data Guard setup concurrently on different databases within the same Oracle home.
  • Perform Data Guard actions (switchover, failover, and reinstate) concurrently on different databases within the same Oracle home.
  • Perform Data Guard setup while simultaneously updating VM Cluster tags.
  • Create or delete a PDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.

To terminate a Data Guard Group on an Exadata Cloud Infrastructure instance

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

  1. Open the navigation menu. Click Oracle AI 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 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.

  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.

Using the API to manage Data Guard associations

Use these API operations to manage Data Guard associations on an Exadata Cloud Infrastructure instance:

Note

In February 2026, the Data Guard Association model and its associated APIs will be replaced by the new Data Guard Group model and APIs. Beginning February 2026, all new Data Guard configurations provisioned from the Oracle Cloud Infrastructure (OCI) Console will automatically use the Data Guard Group model.

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.

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