Verify the Configuration

When the DR setup is complete, immediately validate that the setup is correct by performing a complete switchover or by opening the secondary site for validation. Opening the secondary site for validation will not affect the system running in primary.

Open the Secondary for Validation

You can validate the standby site without performing a complete switchover by converting the standby database to snapshot standby. This allows the secondary WebLogic Server servers to be started in the standby site and verify the secondary system. Any change performed in the standby site database while it is in snapshot standby mode will be discarded once it is converted to physical standby again. Primary data isn't affected by secondary site validations.

Note:

This operation must be done with caution: if there are pending JMS messages in the database when it is converted into snapshot, the standby site’s servers will process them when they start. Check that there are no pending actions in the primary database when converting to snapshot standby.

As an oracle user, use Oracle Data Guard broker in the primary db host and convert the secondary into a snapshot standby.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Use the command show configuration to verify that the conversion has been performed correctly.
If they are not already up, start the Oracle HTTP Server systems in the secondary site.
Start the Admin Server in the secondary site.
Start the secondary managed servers in the secondary site.
Use the WebLogic Console or scripts to start the secondary managed servers.
Validate the secondary site.

As this is not a switchover and the primary site is still active, the virtual front-end name will resolve to the primary site’s load balancer IP address, so any browser access will, by default, be redirected to the active primary site.

To directly access the secondary site’s WebLogic Server applications, you must update the /etc/hosts file in a controlled client (for example, a laptop), set the virtual front-end name to resolve to the secondary site’s front-end load balancer IP address, and run any validation from this client.

Note:
Verify that the client used for validations does not access the system through an HTTP proxy, because the HTTP proxy may continue to resolve the virtual front-end name with the primary site’s load balancer IP address regardless of which name is in the /etc/hosts of the client.

Non-Linux clients may require a reset of their local DNS cache before a browser will resolve the IP address using the customized host file entry.

Once the secondary site has been validated, go to the next step to revert it back to the standby role.

Note:
It might take time to validate the secondary site.
Stop the managed servers and admin servers in the secondary site.
Use the secondary WebLogic Console to shut down the managed servers and Admin server in the secondary site.
As an oracle user, use Oracle Data Guard broker in the primary database host and convert the secondary to physical standby again.
You'll need your system password and the unique name of your primary database.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Use show configuration to verify the conversion.
Revert back any updated /etc/hosts files.
If you updated any /etc/hosts files in a client to point to the secondary site for validations, then revert back so the virtual front-end name points to primary front-end IP address again.

Perform a Switchover

A switchover is a planned operation where an administrator reverts the roles of the two sites. After a switchover, the primary system becomes secondary and the secondary system becomes primary. Performing a switchover will cause downtime in the primary site.

Before performing a switchover in a WebLogic Server Hybrid DR configuration, propagate any pending configuration changes. Ensure there aren't any replicated changes to the secondary site pending.

Disable any scheduled replication while the switchover is performed, since it may fail and interfere with the switchover operation itself.
Stop the Oracle HTTP Server systems in the primary site.
Stop the servers in the primary site.
Use the WebLogic Administration Server Console or scripts to stop the WebLogic servers in the primary site.

Note:
The Admin server in primary site can remain up during switchover. However, it is recommended to stop it when the site is in standby role because it is expected that the domain configuration in the standby site will be overridden by the primary configuration during the lifecycle. If the Admin server is up while this happen, it will be running with a stale configuration.
Switchover the front-end DNS name.

Perform the required DNS push in the DNS server hosting the names used by the system or alter the file host resolution in clients to point the front-end virtual name of the system to the public IP used by the Load Balancer in the secondary site.

For scenarios where DNS is used for the external front-end resolution (such as OCI DNS or commercial DNS), you can use an API to push the change. To see an example that pushes this change in an OCI DNS, go to GitHub for example scripts.

Note that the TTL value of the DNS entry will affect the RTO of the switchover: if the TTL is high (example, 20 min), the DNS change will take that time to be effective in the clients. Using lower TTL values will make this to be faster; however, this can cause an overhead because clients will hit the DNS more frequently instead of using cached names. A good approach is to set the TTL to a low value temporarily (for example, 1 min), before the change in the DNS. Then, perform the change, and once the switchover procedure is completed, revert the TTL to its original value again.
As an oracle user, use Oracle Data Guard broker in the primary database host to perform the database switchover.
You'll need your system password and the unique name of your primary database.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
If they are not already up, start the Oracle HTTP Server systems in the secondary site (new primary).
Start the Admin Server in the secondary site (new primary), or restart the server if it was already started.
Starting the Admin Server enables configuration changes that were replicated while this was a standby to take effect.
Start the secondary managed servers in the secondary site (new primary).
Use the WebLogic Console or scripts to start the secondary managed servers.