Your database will fail over in minutes. Your EBS won't.
That single sentence is the thing most Oracle E-Business Suite disaster recovery plans get wrong. Data Guard makes the database side genuinely fast and genuinely well-understood. The application tier is where your real recovery time lives — and it is the part nobody rehearses.
EBS is two problems, not one
Almost every DR conversation about E-Business Suite starts in the wrong place, because people think of EBS as one system. For recovery purposes it is two, and they fail differently:
- The database tier — solvable, well-trodden, automatable. Oracle Data Guard has been doing this for two decades.
- The application tier — WebLogic, concurrent managers, forms, and a configuration that is pinned to hostnames. This is the awkward one.
Get this distinction wrong and you will build a DR plan that reports a four-minute RPO and then takes most of a day to actually serve a user.
The architecture
Oracle's EBS Cloud Manager can provision a disaster recovery environment in a second OCI region, walking through the environment details, database tier, application tier and a review step. The diagram below shows what that produces and, more importantly, where the manual work stays.
The database half: Data Guard and your real RPO
The primary database ships redo continuously to a physical standby in the second region. The standby applies it. This part is mature technology and it works.
Your recovery point objective is not a property of the product — it is a choice you make through the Data Guard protection mode, and it is a genuine trade-off:
- Maximum Performance — asynchronous. The primary never waits for the standby. You accept the possibility of losing the last few seconds of transactions.
- Maximum Availability / Maximum Protection — synchronous. Zero data loss, paid for in commit latency on every single transaction, on a link that crosses regions.
Anyone who tells you they want zero data loss and no performance impact has not been shown this trade-off. Make them choose it explicitly, with the latency number in front of them, and put it in writing — because after an outage nobody remembers agreeing to lose thirty seconds of orders.
Two operational details that quietly break DR builds: the TDE wallet must exist on both sides, and the standby must be reachable on the network path you think it is. Both are trivial to fix in advance and painful to discover during a failover.
The application half: AutoConfig, and why EBS isn't push-button
Here is the part that gets glossed over. E-Business Suite is not currently a native member resource of OCI Full Stack Disaster Recovery, and EBS environments have to be failed over manually — because AutoConfig has to run to reconfigure services for the standby site.
EBS's configuration is bound to hostnames. When you activate the standby, the application tier does not simply wake up pointing at the right database on the right hosts. AutoConfig has to regenerate that configuration. That is a real, sequenced, human-supervised procedure:
- Activate the standby database.
- Run AutoConfig to repoint services at the standby hosts.
- Start the application services.
- Redirect users — DNS, load balancer, or whatever fronts the estate.
None of those steps are hard. All of them take time, and they take longer at 3am during a real incident than they did on the runbook.
So what actually sets your RTO?
Not Data Guard. The database failover is the quick bit. Your recovery time objective is set almost entirely by:
- How long AutoConfig takes on your estate — which depends on how many nodes and how much customisation you carry.
- How long application services take to start and warm.
- How fast you can redirect users.
- Honestly? How confident the person running the procedure is. Which is a function of how recently they last did it.
This is why an untested DR plan is not a plan. It is a document. If you have never run the failover, you do not have an RTO — you have an estimate, and estimates about EBS application tiers are usually optimistic.
The questions worth asking about your own DR
| Question | Why it matters |
|---|---|
| When did you last actually fail over? | If the answer is “never”, your RTO is fiction. |
| Which Data Guard protection mode are you in? | It defines your RPO. Many teams cannot answer this. |
| Is the TDE wallet on the standby? | A cheap thing to check now, an outage-extending surprise later. |
| Who runs AutoConfig at 3am? | A DR plan that depends on one person is a single point of failure with a pulse. |
| Do your customisations survive the failover? | Custom top, interfaces and integrations often point at the primary by name. |
The summary
EBS Cloud Manager makes standing up a cross-region standby dramatically less painful than building one by hand, and Data Guard makes the data side a solved problem. Neither makes E-Business Suite failover push-button, because AutoConfig sits in the middle and EBS isn't a native Full Stack DR resource.
That is not a criticism of the architecture — it is just what it is. The teams that recover well are not the ones with the best diagram. They are the ones who have run the procedure recently enough to trust it.
This article is part of the ROSTAN Oracle Knowledge Hub — our engineering guidance on Oracle EBS, Fusion Cloud, APEX, Database 23ai and OCI, organised by topic.
