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

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.

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

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.

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.

Learn to enable Data Guard association between databases.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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:
     • Select a Data Guard type, Active Data Guard or Data Guard, based on the Oracle Database software license type you have deployed. If you have deployed Oracle Database Enterprise Edition Extreme Performance (License Included), then you may choose either Data Guard or Active Data Guard. If you have deployed Bring Your Own License (BYOL) Oracle Database Enterprise Edition without the Active Data Guard option, then you would select Data Guard, which is the default.
       • Active Data Guard: Active Data Guard is a licensed option to the Oracle Database Enterprise Edition and enables advanced capabilities that extend the basic Data Guard functionality. These capabilities include Real-Time Query and DML Offload, Automatic Block Repair of physical data corruptions, Standby Block Change Tracking, Far Sync, Global Data Services, and Application Continuity.
       • Data Guard: Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. 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. Data Guard maintains these standby databases as transactionally consistent copies of the production database.

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

       Maximum Availability provides the highest level of protection of data with zero data loss synchronous transport without compromising the availability of the database.

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

       Async - Asynchronous transport mode used with Maximum Performance protection mode.

       Sync - Synchronous transport mode used with Maximum Performance and Maximum Availability protection mode.

   • Select peer VM cluster: Specify the following values for the standby:
     • Peer Region: The primary and standby databases could be running on two different VM clusters on a shared ExaDB-C@C system or on two geographically separated ExaDB-C@C systems managed from the same or different Oracle Cloud Infrastructure regions.
     • Peer Exadata: Select the Exadata Database Service on 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.
   • Choose Database Home: Select an existing Database Home or create one as applicable.
     • Select an existing Database Home: If one or more Database Homes already exist for the database version you have selected, then this option is selected by default. And, you will be presented with a list of Database Homes. Select a Database Home from the list.
       Note
       
       Although only Database homes of the same version and RU are listed, the homes displayed may have different one-off patches than the primary. Though acceptable to have different one-offs, the best practice is to have identical database homes between primary and standby.
     • Create a new Database Home: If no Database Homes exist for the database version you have selected, then this option is selected by default. You can create the new Database Home with the same DSI as the primary database, or choose a different image. Note that DSIs are not available across regions. A separate DSI must be created in the peer region using the same RU as the primary.
       1. Click Change Database Image to select a database software image for the new Database Home.
       2. In the resulting Browse Database Images, 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 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.
          3. Click Select.
   • Configure standby database:
     • Provide a unique name for the database:
       Note
       
       You cannot modify the db_name, db_unique_name, and SID prefix after creating the database.

       Optionally, specify a unique name for the database. This attribute defines the value of the db_unique_name database parameter. The value is case insensitive. The db_unique_name must contain only the permitted characters.

       Review the following guidelines when selecting a database name:

       • maximum of 30 characters
       • can contain alphanumeric and underscore (_) characters
       • begin with an alphabetic character
       • unique across the fleet/tenancy

       If a unique name is not entered, then the db_unique_name defaults to the following format <db_name>_<3 char unique string>_<region-name>.

     • Database password: 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.

   • (Optional) Select Show Advanced Options.
     • Provide the Oracle SID prefix: Optionally, specify the Oracle SID prefix for the database. The instance number is automatically appended to the SID prefix to become the instance_name database parameter. If not provided, then the SID prefix defaults to the first 12 characters of the db_unique_name.
       Review the following guidelines when selecting a database name:

       • maximum of 12 characters
       • contain only alphanumeric characters
       • begin with an alphabetic character
       • unique in the VM cluster
7. Click Enable Data Guard.

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

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Choose your Compartment.
3. Click on the VM Cluster containing 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.

You can switch between Data Guard types based on the Oracle Database software license type you have deployed.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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 Data Guard type.
4. Click the name of the primary database.
5. Under Resources, click Data Guard Associations.

   A list of Data Guard Associations is displayed with the Data Guard Type you have chosen for each Data Guard Association.

6. To edit Data Guard Association details, click the Actions icon (three dots), and then click Edit Data Guard Association.

   Edit Data Guard Association screen is displayed.

7. Do the following on the Edit Data Guard Association screen.
   • Select an applicable Data Guard type.
   • Select the Protection mode.
     Note
     
     You cannot edit the Transport type. This field is updated automatically based on the Protection mode you select.
   • Set the Database password.
   • Click Edit Data Guard to save the changes.

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

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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.

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

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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.

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.

srvctl stop database -d db-unique-name -o abort

srvctl start database -d db-unique-name -o mount

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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.
4. Click the name of the primary database.
5. Under Resources, click Data Guard Associations.

   You will see the database you want to reinstate listed.

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

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

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on 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.