Use Oracle Data Guard with Oracle Exadata Database Service on Cloud@Customer
Learn to configure and manage Data Guard associations in your VM cluster.
- About Using Oracle Data Guard with Oracle Exadata Database Service on Cloud@Customer
This topic explains how to use the Console or the API to manage Data Guard associations in your VM cluster. - Prerequisites for Using Oracle Data Guard with Oracle Exadata Database Service on Cloud@Customer
Review the list of prerequisites for using Data Guard with Oracle Exadata Database Service on Cloud@Customer. - Working with Data Guard
Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. - 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. - Using the API to Manage Data Guard Associations on an Oracle Exadata Database Service on Cloud@Customer System
Learn how to use the API to manage Data Guard associations on an Oracle Exadata Database Service on Cloud@Customer system.
Parent topic: How-to Guides
About Using Oracle Data Guard with Oracle Exadata Database Service on Cloud@Customer
This topic explains how to use the Console or the API to manage Data Guard associations in your VM cluster.
- The standby database is a physical standby.
- The versions of peer databases (primary and standby) are identical.
- You are limited to one standby database for each primary database.
- The standby database is deployed as an open, read-only database (Active Data Guard).
To configure a Data Guard system 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.
Prerequisites for Using Oracle Data Guard with Oracle Exadata Database Service on Cloud@Customer
Review the list of prerequisites for using Data Guard with Oracle Exadata Database Service on Cloud@Customer.
- VM Clusters
A VM cluster Data Guard implementation requires two Exadata database VM Clusters, one containing the primary database and one containing the standby database. - Password
For Data Guard operations to work, theSYS
password and the TDE wallet password of the primary and standby databases must all be the same. - Adding a Node to a VM Cluster
- Removing a Node from a VM Cluster
VM Clusters
A VM cluster Data Guard implementation requires two Exadata database VM Clusters, one containing the primary database and one containing the standby database.
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.
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.
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 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. - 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 association.
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.
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.
A failover might result in some data loss when you use Maximum Performance protection mode.
Parent topic: Working with Data Guard
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.
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 the former primary.
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.
Parent topic: Working with Data Guard
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 Oracle Exadata Database Service on Cloud@Customer System
Learn to enable Data Guard association between databases. - Using the Console to View Data Guard Associations of Databases in an Exadata VM Cluster
To view the role of each database in a Data Guard association in an Exadata VM Cluster, follow this procedure. - Using the Console To View and Edit Data Guard Associations
You can switch between Data Guard types based on the Oracle Database software license type you have deployed. - Using the Console To Perform a Database Switchover
You initiate a switchover operation by using the Data Guard association of the primary database. - Using the Console To Perform a Database Failover
You initiate a failover operation by using the Data Guard association of the standby database. - 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. - Using the Console To Terminate a Data Guard Association on an Oracle Exadata Database Service on Cloud@Customer System
On a VM cluster, you remove a Data Guard association by terminating the standby database.
Using the Console to Enable Data Guard on an Oracle Exadata Database Service on Cloud@Customer System
Learn to enable Data Guard association between databases.
Data Guard relies on a reliable network with sufficient throughput between the primary and standby clusters. Since Oracle does not own the network, some evaluation should be done prior to implementing Data Guard to ensure the required network bandwidth is available. It is recommended that Assessing and Optimizing Network Performance be followed to understand the achievable throughput between the clusters and evaluate whether the requirements of the database are met. By default, the maximum socket buffer size is set to a higher value for cross-region ExaDB-C@C Data Guard configurations.
When you configure the Data Guard association for 23ai databases, the primary and standby databases must be on the same major release version while the standby database can be on a higher minor version.
Using the Console to View Data Guard Associations of Databases in an Exadata VM Cluster
To view the role of each database in a Data Guard association in an Exadata VM Cluster, follow this procedure.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Choose your Compartment.
- Click on the VM Cluster containing the databases you wish to view their roles in Data Guard associations.
- In the Databases section under Resources, the role of each database in this VM Cluster is indicated in the Data Guard role column.
Using the Console To View and Edit Data Guard Associations
You can switch between Data Guard types based on the Oracle Database software license type you have deployed.
Using the Console To Perform a Database Switchover
You initiate a switchover operation by using the Data Guard association of the primary database.
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.
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.
ORACLE_UNQNAME
environment variable to the
value of the Database Unique Name, and then run these
commands:srvctl stop database -d db-unique-name -o abort
srvctl start database -d db-unique-name -o mount
This database should now be reinstated as the standby in the Data Guard association.
Using the API to Manage Data Guard Associations on an Oracle Exadata Database Service on Cloud@Customer System
Learn how to use the API to manage Data Guard associations on an Oracle Exadata Database Service on 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. |
|
View details of the specified Data Guard association's configuration information. |
|
View the list of all Data Guard associations for the specified database. |
|
Perform a switchover to transition a primary database of a Data Guard association into standby role. |
|
Perform a failover to transition a standby database
identified by the |
|
Reinstate a database identified by the
|
For more information, see Using the Console To Reinstate a Database. |
Delete a standby database. |
For the complete list of APIs, see Database Service API.