Using Oracle Data Guard with Exadata Cloud@Customer

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

About Using Oracle Data Guard with Exadata Cloud@Customer

This topic explains how to use the Console or the API to manage Data Guard associations 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 is a physical standby.
  • The peer databases (primary and standby) are in the same compartment and the database versions are identical.
  • You are limited to one standby database for each primary database.

To configure a Data Guard system across regions or between on-premises and Exadata database compute nodes, or to configure your database with multiple standbys, you must access the database host directly and set up 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 Policy for Managing Oracle Data Guard Associations on Oracle Exadata Cloud@Customer

Review the identity access management (IAM) policy for managing Oracle Data Guard associations on Oracle Exadata Cloud@Customer Systems.

A policy is an IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources.

A compartment is a collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization.

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 a software development kit (SDK), a command-line interface (CLI), or some other tool. If you try to perform an action, and receive a message that you don’t have permission, or are unauthorized, then confirm with your administrator the type of access you've been granted, and which compartment you should work in.

For administrators: The policy in "Let database admins manage DB systems" lets the specified group do everything with databases, and related database resources.

If you're new to policies, then see "Getting Started with Policies" and "Common Policies". If you want to dig deeper into writing policies for databases, then see "Details for the Database Service".

Prerequisites for Using Oracle Data Guard with Exadata Cloud@Customer

Review the list of prerequisites for using Data Guard with Exadata Cloud@Customer.

Compute Nodes

A VM cluster Data Guard implementation requires two Exadata database compute nodes, one containing the primary database and one containing the standby database.

When you enable Data Guard for an Exadata database compute node database, the Exadata database compute node with the database to be used as the standby must already exist before you enable Data Guard.

Password

For 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, you must update the rest of the passwords to match.

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

Working with Data Guard

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

The Data Guard implementation requires two databases, one in a primary role and one in a standby role. The two databases compose a Data Guard association. Most of your applications access the primary database. The 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 switch or fail over the standby database to the primary role.

Switchover

A switchover reverses the primary and standby database roles.

Each database continues to participate in the Data Guard association 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 a Exadata database compute node with a Data Guard association 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.

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 a Data Guard association.

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

Note

You can't terminate a primary database that has a 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 can't terminate a VM cluster that includes Data Guard enabled databases. You must first remove the Data Guard association by terminating the standby database.

Using the Console to Manage Oracle Data Guard Associations

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

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

Using the Console to Enable Data Guard on an Exadata Cloud@Customer System

Learn to enable Data Guard association between databases.

  1. Open the navigation menu. Under Database, click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the VM cluster that contains the database for which you want to assume the primary role, and then click the name of that database.
  4. Under Resources, click Data Guard Associations.
  5. Click Enable Data Guard.
  6. On the Enable Data Guard page, configure your Data Guard association.
    • Data Guard association details:
      • Protection mode: The protection mode used for this Data Guard association.

        Maximum Performance provides the highest level of data protection that is possible without affecting the performance of a primary database.

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

        The redo transport type used for this Data Guard association. Async - Asynchronous transport mode used with Maximum Performance protection mode.

    • Select peer VM cluster: Specify the following values for the standby:
      • Peer Region: Currently, the peer region is auto-populated and you cannot change it. The primary and secondary databases could be running on two different VM clusters on a shared Exadata Cloud@Customer system, or on two geographically separated Exadata Cloud@Customer systems managed from a single Oracle Cloud Infrastructure region.
      • Peer Exadata: Select the Exadata Cloud@Customer infrastructure where the standby database is located. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
      • Peer VM Cluster: Select the Exadata database compute node that contains the standby database. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
    • Configure standby database: Enter the database admin password of the primary database in the Database password field. This same database admin password will be used for the standby database.

      The admin password and the TDE password must be the same. If they are not, follow the instructions in Changing the Database Passwords to align them.

  7. Click Enable Data Guard.

When the association is created, the details for a database and its peer display their respective roles as Primary or Standby.

Using the Console To Perform a Database Switchover

You initiate a switchover operation by using the Data Guard association of the primary database.

  1. Open the navigation menu. Under Database, click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the VM cluster that contains the primary database you want to switch over.
  4. Click the name of the primary database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to perform a switchover, click the Actions icon (three dots), and then click Switchover.
  7. In the Switchover Database dialog box, enter the database admin password, and then click OK.

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

Using the Console To Perform a Database Failover

You initiate a failover operation by using the Data Guard association of the standby database.

  1. Open the navigation menu. Under Database, click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the VM cluster that contains the primary database's peer standby you want to fail over to.
  4. Click the name of the standby database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to perform a failover, click the Actions icon (three dots), and then click Failover.
  7. In the Failover Database dialog box, enter the database admin password, and then click OK.

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

Using the Console 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 by using its Data Guard association.

Before you can reinstate a version 12.2 or later database, you must perform some steps on the database host to stop the database or start it in MOUNT mode.

Set your ORACLE_UNQNAME environment variable to the value of the Database Unique Name (as seen in the ), and then run these commands:
srvctl stop database -d db-unique-name -o abort
srvctl start database -d db-unique-name -o mount
  1. Open the navigation menu. Under Database, click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the VM cluster that contains the failed database you want to reinstate.
  4. Click the name of the failed database.
  5. Under Resources, click Data Guard Associations.
  6. For the Data Guard association on which you want to reinstate this database, click the Actions icon (three dots), and then click Reinstate.
  7. In the Reinstate Database dialog box, enter the database admin password, and then click OK.

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

Using the Console To Terminate a Data Guard Association on an Exadata Cloud@Customer System

On a VM cluster, you remove a Data Guard association by terminating the standby database.

  1. Open the navigation menu. Under Database, click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the VM cluster that contains the standby database you want to terminate.
  4. Click the name of the standby database.
  5. For the standby database you want to terminate, click the Actions icon (three dots), and then click Terminate.
  6. In the Terminate Database dialog box, enter the name of the database, and then click OK.

Using the API To Manage Data Guard Associations on an Exadata Cloud@Customer System

Learn how to use the API to manage Data Guard associations on an Exadata Cloud@Customer system.

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.

The following table lists the REST API endpoints to manage Data Guard associations.

Operation REST API Endpoint

Create a Data Guard association.

CreateDataGuardAssociation

View details of the specified Data Guard association's configuration information.

GetDataGuardAssociation

View the list of all Data Guard associations for the specified database.

ListDataGuardAssociations

Perform a switchover to transition a primary database of a Data Guard association into standby role.

SwitchoverDataGuardAssociation

Perform a failover to transition a standby database identified by the databaseId parameter into the specified Data Guard association's primary role after the existing primary database fails or becomes unreachable.

FailoverDataGuardAssociation

Reinstate a database identified by the databaseId parameter into standby role in a Data Guard association.

ReinstateDataGuardAssociation

Delete a standby database.

DeleteDatabase

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