What’s Supported?

The Oracle-managed disaster recovery solution provides support for the following features.

Is Disaster Recovery Supported for Existing Instances?

Only new instances are supported. You cannot configure a disaster recovery solution for an existing instance.

As an alternative, you can export the design-time metadata from your existing Oracle Integration 3 instance and import it into a new, disaster recovery-enabled instance:
  1. See What’s Not Supported? to review which features are not currently supported in disaster recovery environments. This helps you determine if moving your existing Oracle Integration 3 instance metadata to a new, disaster recovery-enabled Oracle Integration 3 instance impacts your current functionality.
  2. If you want to continue with the export and import process:
    1. Create a new, disaster recovery-enabled instance. See Set Up and Perform Disaster Recovery.
    2. Clone (create) an archive of integration design-time metadata for export from the existing Oracle Integration 3 instance.
    3. Import the archive into the new, disaster recovery-enabled Oracle Integration 3 instance.

    See Clone the Design-Time Metadata of an Entire Service Instance in Using Integrations in Oracle Integration 3.

What Features are Supported?

  • Integrations and File Server components.
  • B2B for Oracle Integration
  • Enterprise edition and Healthcare edition. See Install and Configure Oracle Integration for Disaster Recovery.
  • Active-passive topologies. Only one instance of the disaster recovery configuration can be active and processing transactions at a time.

    Active-passive topologies mean that only one instance processes all the load even though both instances are expected to be up and running. An active instance is determined by which instance the traffic is directed to and is enabled to execute all functions, and not by its start or stop status. It is recommended that you not turn off your disaster recovery instance.

  • Oracle-managed synchronization (replication) of design-time metadata only.
  • Private endpoints. As a prerequisite to failover, you must explicitly enable private endpoints on the primary and secondary instances before performing a failover. See Enable Private Endpoints on the Primary and Secondary Instances.
  • Access control lists (ACLs). As a prerequisite to failover, you must explicitly enable ACLs on the primary and secondary instances before performing a failover. See Restrict Access to an Instance Using the Self-Service Allowlist.
  • Integration instances running with polling endpoints (for example, integrations involving Oracle Cloud Infrastructure Streaming, databases, JMS, and others) are automatically activated after failover.
  • A recovery point objective (RPO) period of one hour. The RPO is the period after a disaster occurs during which the service can tolerate lost data before the disaster begins to affect the business.
  • A recovery time objective (RTO) period of one hour. The RTO is the target time within which your service must be restored to the secondary system after a failover request.
  • User-initiated failover (not automatic). When your current primary instance becomes unreachable, you manually select the Start failover option in the Oracle Cloud Infrastructure Console of the secondary instance to fail over to that instance. See Fail Over to the Other Instance.
  • Extended data retention.

    If you have data retention set to more than 30 days on the primary instance and then fail over to the secondary instance, those settings are retained on the secondary instance.

What Regions are Supported?

Disaster recovery instances in the following regions. Each region is paired for failover with another region.

This Region... Is Paired with this Region...
Ashburn (IAD) Phoenix (PHX)
Dubai (DXB) Abu Dhabi (AUH)
Germany Central (FRA) Netherlands Northwest (AMS)
London UK (LHR) Newport UK (CWL)
Singapore (SIN) Japan East (Tokyo) (NRT)
Sydney (SYD) Melbourne (MEL)
Toronto (YYZ) Montreal (YUL)
Jeddah (JED) Riyadh (RUH)