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

Plan the Configuration

Plan the resources and configuration on the primary system on Oracle Cloud Infrastructure before creating the secondary system.

Choose a Snapshot Standby or Remote Refreshable Clone

Review the following to determine if you want to use a Snapshot Standby or Remote Refreshable Clone.

Note:

Remote Refreshable Clone is only available with Oracle Autonomous Database Serverless.

If you're using Oracle Autonomous Database on Dedicated Exadata Infrastructure, then use the snapshot standby feature for the setup and lifecycle. Oracle Autonomous Database on Dedicated Exadata Infrastructure does not implement the remote refreshable clone feature.

If you're using Oracle Autonomous Database Serverless, then you can use Remote Refreshable Clone or the snapshot standby feature for the setup and lifecycle. Consider the following to decide:

Snapshot Standby

  • Advantages:
    • The setup and lifecycle operations are easier. You don’t need to modify the wallet in secondary when you convert the standby to snapshot or back to physical standby.
    • The snapshot standby does not require an additional database in the standby region. There is only the standby database, that you can convert to a snapshot and back to a physical standby.
    • When you use the standby in snapshot standby for validating the secondary, you're really using the same autonomous database that you'll use in case of a switchover. So, your validation is more realistic in terms of connectivity because you use the same wallet that you will use in the event of a switchover.
  • Disadvantages:
    • While the standby database is in snapshot standby mode, the standby database receives but doesn't apply, the redo from primary. If you must perform an urgent failover or switchover while you are testing the secondary, you'll first need to convert it to physical standby, so that it gets synced with primary. This can introduce some delay in the switchover time.

Remote Refreshable Clone

  • Advantages:
    • The remote refreshable clone is a separate autonomous database. You don’t directly interact with the standby database when you setup the standby mid-tier or when you test secondary during the lifecycle.
  • Disadvantages:
    • As it is a separate autonomous database, it is billed as an additional autonomous database instance.
    • The setup and lifecycle operations are more complex. You must switch the wallet between the real standby database and the remote refreshable clone every time to point to one or to the other.

Choosing one approach or another does not force you to use the same approach throughout the system’s life. As long as you use the appropriate steps, you can use a different approach during the lifecycle from the approach that you use for the disaster recovery setup. You can also combine a snapshot standby for some operations with a refreshable clones for other tests. For example, use snapshot for provisioning and workload verifications on secondary, but use a refreshable clone for sparse tests while the system is under heavy load. This way you can avoid the overhead (and possible switchover delays) caused by massive redo apply in the conversion from snapshot to physical standby.

Considerations for the Primary System

It is assumed that the primary Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace, or Oracle Fusion Middleware system is created and is using the Oracle Autonomous Database service. When planning to implement a secondary system in Oracle Cloud Infrastructure (OCI), review the following considerations for the primary system:
  • Private Subnet

    Both Oracle Autonomous Database and Oracle SOA Suite on Marketplace are placed in a private subnet.

  • Private End Point when using Oracle Autonomous Database Serverless

    The Oracle Autonomous Database Serverless system is exposed through a Private End Point (PEP).

  • Oracle Cloud Infrastructure Load Balancing

    A front end OCI Load Balancer exposes the Oracle WebLogic Server for OCI, Oracle SOA Suite on Marketplace, or Oracle Fusion Middleware system.

    The OCI Load Balancer can be public or private, depending on the client access requirements. For implicit High Availability features in multi-AD regions, place the OCI Load Balancer in a regional subnet.

  • Oracle Cloud Infrastructure File Storage

    The Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace, or Oracle Fusion Middleware system DR system uses a Oracle Cloud Infrastructure File Storage mount that is shared by the different nodes in the WebLogic clusters. The mount is used to replicate the configuration across regions.

    • Oracle SOA Suite on Marketplace system allows you to create a new file storage or reuse an existing file storage. It mounts in the /u01/soacs/dbfs/share/ directory. Despite the name of this directory, this is NOT an Oracle Database File System (DBFS) mounted directory for Oracle Autonomous Database. Ensure that you select Configure File Storage in your Oracle SOA Suite on Marketplace stack. You can select the option during provisioning or post-provisioning.
    • Oracle WebLogic Server for Oracle Cloud Infrastructure system allows you to create new file storage or reuse existing files storage (mounted in the /u01/shared directory). Ensure that you select Add File System in your Oracle WebLogic Server for OCI stacks. You can select the option during provisioning or post-provisioning.
    • For other services, you might need to manually create the OCI File Storage mount in both the primary and secondary middle tier nodes. If not using Oracle WebLogic Server for Oracle Cloud Infrastructure or Oracle SOA Suite on Marketplace, then see the OCI File Storage documentation for details and steps for creating the storage.