What’s Supported?

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

  • 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.
  • 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)
  • New instances only. You cannot configure a disaster recovery solution for an existing instance.
  • 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.