Use Oracle Data Guard with Oracle Exadata Database Service on Exascale Infrastructure
Learn to configure and manage Data Guard associations in your VM cluster.
- About Using Oracle Data Guard with Oracle Exadata Database Service on Exascale Infrastructure
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 Exascale Infrastructure
An 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 Data Guard standby database. - Working with Oracle 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
Use these API operations to manage Data Guard associations on an Oracle Exadata Database Service on Exascale Infrastructure instance:
Parent topic: How-to Guides
About Using Oracle Data Guard with Oracle Exadata Database Service on Exascale Infrastructure
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 Exascale Infrastructure
An 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 Data Guard standby database.
When enabling Oracle Data Guard, you can create a new Database Home on the standby Exadata instance to house the new standby database during the enable Data Guard operation. Alternately, you can choose to provision the standby database in an existing Database Home on the standby instance.
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.
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. :
If you are creating an Oracle Data Guard Association 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.
- Network Requirements for Data Guard
Ensure that you meet the requirements for using Oracle Exadata Database Service on Exascale Infrastructure with Oracle Data Guard. - Password Requirements
For Data Guard operations to work, theSYS
password and the TDE wallet password of the primary and standby databases must all be the same. - Known Issues for Exadata Cloud Infrastructure and Data Guard
Possible TDE key replication issue, and MRP and DG LCM operation failures. - Adding a Node to a VM Cluster
If node addition is done either on the standby database or the primary database, the metadata must be updated manually on the database other than the one where the node was added. - Removing a Node from a VM Cluster
If node removal is done either on the standby database or the primary database, the metadata must be updated manually on the database other than the one where the node was removed.
Network Requirements for Data Guard
Ensure that you meet the requirements for using Oracle Exadata Database Service on Exascale Infrastructure with Oracle Data Guard.
Ensure that your environment meets the following network requirements:
-
The primary and standby databases can be part of VM clusters in different compartments.
-
The primary and standby databases must, however, be part of the same VCN within the same region.
-
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 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 Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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 Oracle Exadata Database Service on Exascale 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
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. 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), 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.
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
If node addition is done either on the standby database or the primary database, the metadata must be updated manually on the database other than the one where the node was added.
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
If node removal is done either on the standby database or the primary database, the metadata must be updated manually on the database other than the one where the node was removed.
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 Oracle 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
With Oracle Data Guard, a failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable. - Reinstate
The reinstate command reinstates a database into the standby role in an Oracle 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 virtual machine 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 Oracle Data Guard
Failover
With Oracle Data Guard, 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 Oracle Data Guard
Reinstate
The reinstate command 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 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 Oracle 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.
- To enable Data Guard on Exadata Database Service on Exascale Infrastructure
Learn how to enable Data Guard association between databases. - To view Data Guard associations of databases in a Cloud VM Cluster
To view the role of each database in a Data Guard association in an Cloud VM Cluster, follow this procedure. - To enable automatic backups on a standby database
Learn to enable automatic backups on a standby database. - To perform a database switchover
You initiate a switchover operation by using the Data Guard association of the primary database. - To edit the Oracle Data Guard association
You edit the Oracle Data Guard association to configure the Data Guard protection for the primary database. - To perform a database failover
You initiate a failover operation by using the Data Guard association of the standby database. - 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. - To terminate a Data Guard association on an Oracle Exadata Database Service on Exascale Infrastructure instance
On an Oracle Exadata Database Service on Exascale Infrastructure instance, you remove a Data Guard association by terminating the standby database.
To enable Data Guard on Exadata Database Service on Exascale Infrastructure
Learn how to enable Data Guard association between databases.
Note:
When you enable Data Guard, replication of data happens only over the client network.A work request is issued to configure the Data Guard association. The progress of the request and the stages of provisoning an be viewed on the Work Requests page.
When the association is created, the details for a database and its peer display their respective roles as Primary or Standby.
- View Data Guard Provisioning Progress
View the progress of Data Guard Provisioning tasks using the Work Requests page.
Related Topics
View Data Guard Provisioning Progress
View the progress of Data Guard Provisioning tasks using the Work Requests page.
After you have completed the task To Enable Data Guard, multiple work requests are issued to complete the provisioning of the Data Guard association. To veiw the progress of these work requests:
- Navigate to the Work Requests Details page. On the Work Requests Details page there is a bar in the Work Request Information tab that shows the overall progress of the Data Guard Provisioning
- Under Resources, select Log Messages. The table shows a messsage for each task that is completed or in progress.
To view Data Guard associations of databases in a Cloud VM Cluster
To view the role of each database in a Data Guard association in an Cloud VM Cluster, follow this procedure.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Exascale Infrastructure.
- Choose your Compartment.
- Navigate to the cloud VM cluster that contains 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.
To enable automatic backups on a standby database
Learn to enable automatic backups on a standby database.
To perform a database switchover
You initiate a switchover operation by using the Data Guard association of the primary database.
- Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
- Choose the Compartment that contains the Oracle Exadata Database Service on Exascale Infrastructure instance with the database for which you want to enable Oracle Data Guard.
-
Navigate to the cloud VM cluster or DB system that contains the Data Guard association:
Oracle Exadata Database Service on Exascale 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.
- Under Resources, click Data Guard Associations.
- For the Data Guard association on which you want to perform a switchover, click the Actions icon (three dots), and then click Switchover.
-
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.
To edit the Oracle Data Guard association
You edit the Oracle Data Guard association to configure the Data Guard protection for the primary database.
- Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
- Choose the Compartment that contains the Exadata Cloud Service instance with the database for which you want to enable Oracle Data Guard.
-
Navigate to the cloud VM cluster or DB system that contains the Data Guard association:
Under Oracle Exadata Database Service on Exascale 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.
- Under Resources, click Data Guard Associations.
- For the Data Guard association you want to manage, click the Actions
menu (
), and then click Edit Protection Mode. -
In the Edit Data Guard Association panel, configure the Data Guard association:
- 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 Oracle Data Guard association.
- Database admin password: Enter the ADMIN password for the database.
- Click Save.
Related Topics
To perform a database failover
You initiate a failover operation by using the Data Guard association of the standby database.
- Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
- Choose the Compartment that contains the Oracle Exadata Database Service on Exascale Infrastructure instance with the database for which you want to enable Oracle Data Guard.
-
Navigate to the cloud VM cluster that contains the Data Guard association:
Under Oracle Exadata Database Service on Exascale 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.
- Under Resources, click Data Guard Associations.
- For the Data Guard association on which you want to perform a failover, click Failover.
-
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.
To reinstate a database
- Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
- Choose the Compartment that contains the Oracle Exadata Database Service on Exascale Infrastructure with the database for which you want to enable Oracle Data Guard.
-
Navigate to the cloud VM cluster or DB system that contains the Data Guard association:
Under Oracle Exadata Database Service on Exascale 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.
- Under Resources, click Data Guard Associations.
- For the Data Guard association on which you want to reinstate this database, click the Actions icon (three dots), and then click Reinstate.
-
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.
To terminate a Data Guard association on an Oracle Exadata Database Service on Exascale Infrastructure instance
On an Oracle Exadata Database Service on Exascale Infrastructure instance, you remove a Data Guard association by terminating the standby database.
- Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure.
- Choose the Compartment that contains the Oracle Exadata Database Service on Exascale Infrastructure VM cluster with the database for which you want to enable Oracle Data Guard.
-
Navigate to the cloud VM cluster that contains the standby database:
Under Oracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster that you want to access, and click its highlighted name to view the details page for the cluster.
- For the standby database you want to terminate, click the Actions icon
(
), and then click Terminate. -
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 Oracle Exadata Database Service on Exascale Infrastructure instance:
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.
- CreateDataGuardAssociation
- ListDataGuardAssociations
- GetDataGuardAssociation
- UpdateDataGuardAssociation
- SwitchoverDataGuardAssociation
- FailoverDataGuardAssociation
- ReinstateDataGuardAssociation
- DeleteDatabase - To terminate an Oracle Exadata Database Service on Exascale Infrastructure instance Data Guard association, you delete the standby database.
For the complete list of APIs for the Database service, see Database Service API.