1. Configure Oracle Fusion Middleware DR on Oracle Cloud with an autonomous database
  2. Verify the Configuration

Verify the Configuration

You can validate the standby site without performing a complete switchover by starting the secondary middle tiers and testing with the standby database converted to snapshot standby or with the refreshable clone.

It is recommended that you disable the configuration replication cron job when testing or patching to avoid file corruptions or inconsistencies. The copy from the primary can be maintained, only the replication in the secondary (from the stage directory to the secondary domain) must be disabled during these testing and validation operations.

Refer to the precise Oracle Fusion Middleware components disaster recovery recommendations in case draining is required to avoid duplicate executions of pending workflows, duplicate JMS processing, and so on. Access the standard Oracle WebLogic Administration and Oracle Fusion Middleware consoles to check the appropriate behavior of the system. Note, for testing you might need to manipulate the appropriate DNS because the system is using the primary's front end host name for access).

Open the Secondary Region for Verification When Using Snapshot Standby

Before testing or patching the secondary region, convert the standby database to snapshot standby.

  1. Convert the standby database into snapshot standby.
  2. Once completed, start the Oracle WebLogic Server process in the secondary region normally.
  3. Access the standard Oracle WebLogic Administration and Oracle Fusion Middleware Consoles to check the appropriate behavior of the system (notice that for tests, you might need to manipulate the appropriate DNS since the system is using the primary's front end host name for access)
  4. Once tests are completed, stop the secondary Oracle WebLogic processes.
  5. Convert the standby database into physical standby again.

Open the Secondary Region for Verification When Using Remote Refreshable Clones

Before testing or patching the secondary region, disconnect the refreshable clone from the primary and then change the Oracle WebLogic Server, Oracle SOA, or Oracle Fusion Middleware system DR datasources in the secondary domain from pointing to the standby database to the refreshable clone.

You can change the datasources to point to a Refreshable Clone or back to a standby using the fmwadb_switch_db_conn.sh script.

  1. Use the fmwadb_switch_db_conn.sh script to change the datasources to point to a Refreshable Clone.
    The script uses parameters for a WALLET directory and a WALLET password and it replaces the current wallet directory with the new one as well as the previous wallet password with the one provided.

    The following is an example of executing the replace connection information script:

    [oracle@soarefr-soa-0 ~]$ /u01/soacs/dbfs/share/scripts/fmwadb_switch_db_conn.sh /u01/soacs/dbfs/share/wallets/atp-hyd-refreshable-clone/ my_wallet_password123
The password provided for the wallet is valid. Proceeding...
Gathering Data Soure information...
Backing up current config...
Backup created at /u01/data/domains/soarefr_domain/ /u01/data/domains/soarefr_domain_backup_13_36_11-13-10-22
Replacing values in datasources...
Replacement complete!
  2. Once executed, start the secondary region normally.
  3. Access the standard Oracle WebLogic Administration and Oracle Fusion Middleware Consoles to check the appropriate behavior of the system (notice that for tests, you might need to manipulate the appropriate DNS since the system is using the primary's front end host name for access).
  4. Once tests are completed, revert the datasources to the standby Oracle Autonomous Database Serverless connect information and reconnect the refreshable clone to the primary.
    Use the fmwadb_switch_db_conn.sh script to change the datasources to point back to the standby.