DR for Oracle E Business Suite on OCI

Protecting only the EBS database leaves you with recovered data and no way to serve users. Here is the DR pattern for the whole E Business Suite stack on OCI.

Why E Business Suite is harder than a single database

Oracle E Business Suite is not one thing to protect. It is a database tier, an application tier with concurrent managers and forms and web services, a shared file system, and a web of integrations to other systems. A disaster recovery plan that protects only the database leaves you with a recovered data set and no way to serve users. Protecting EBS means protecting the whole stack and proving it comes up together.

This article covers the disaster recovery pattern for E Business Suite running on OCI, the order things must come up in, and the decisions that separate a plan that works from a plan that only looks complete on paper.

The components you have to account for

The shared file system and the integrations are where most EBS DR plans fall down. The database fails over cleanly, then nobody can log in because the application tier still points at the old database, or a downstream system keeps calling an endpoint that no longer answers.

Database tier with Data Guard

Run a physical standby of the EBS database in the secondary region using Data Guard. The protection mode you choose sets your data loss exposure. Maximum performance gives the best primary throughput with a small lag, while maximum availability holds the primary back to keep the standby in lockstep. Match the mode to the recovery point objective the business signed off. The mechanics are covered in our Data Guard on OCI article, and the broader objective setting in RTO and RPO planning.

Application tier strategy

You have two realistic options for the application tier. The first is to keep pre built application nodes in the secondary region, configured and patched in step with production, ready to start. The second is to build them on demand from a current image during the failover. Pre built nodes give a faster recovery time at a higher steady cost. On demand build is cheaper to run but adds tens of minutes and depends on your automation being current. For a tier one ERP, most organisations keep the nodes pre built.

Whichever you choose, the application tier in the secondary region must be configured for the secondary region database connection and the secondary region addresses. An application node that boots but points at the dead primary is worse than no node at all, because it looks healthy while serving nothing.

The promotion order that actually works

EBS recovery is an ordered sequence, and the order is not negotiable. Promote the database standby first. Confirm the database is open and accepting connections. Reconfigure or confirm the application tier connection details for the promoted database. Start the application services. Start the concurrent processing tier and confirm the managers are running against the right database. Validate with a real login and a test transaction. Only then repoint integrations and external traffic. Doing these out of order, for example starting the application tier before the database is open, produces confusing failures that waste the time you can least afford to lose.

Integrations and the things outside EBS

E Business Suite rarely lives alone. It exchanges data with banks, tax engines, reporting platforms, and custom services. Each of those holds an address for EBS, and each may hold one that EBS calls. Your runbook must list every integration, who owns the endpoint, and how it is repointed during a failover. This is tedious to compile and invaluable during an incident. Build the list once and keep it current.

Patching and keeping the standby aligned

An EBS environment is patched regularly, and every patch that touches the database or the application tier has to reach the secondary region or the standby will not start cleanly when you need it. This is one of the most common reasons an EBS DR plan that worked at go live fails a year later. The production environment moved on and the standby was left behind. Build patching so the secondary region is patched in step with production, and confirm after each cycle that the standby still promotes.

The shared file system needs the same attention. APPL_TOP and the shared mount points must match between regions, so changes to the application tier files have to be replicated, not just the database. A database that fails over perfectly is useless if the application tier in the secondary region is running last quarter code.

Testing EBS disaster recovery

An EBS DR plan must be tested end to end, not component by component. A database switchover test that does not also bring up the application tier and run a transaction proves very little. Schedule a full failover into the secondary region, run a representative set of business transactions, and measure the real recovery time. Our DR testing guide covers how to do this with minimal business disruption, and the backup strategies article covers the safety net beneath it.

Where this sits in the bigger picture

DR for E Business Suite is one workload inside a wider estate. The networking that connects the two regions, the DNS that steers traffic, and the cost model all follow the patterns in the cross region DR guide and the disaster recovery pillar. When we run EBS DR as a managed service, we own the patching alignment, the test cadence, and the recovery itself, so there is no ambiguity about who promotes what when it matters.

Performance and concurrent processing after failover

Many EBS DR designs save money by running a smaller application tier and a smaller database standby in the secondary region. That is a reasonable economy, but it means the recovered environment performs worse than production until you scale it up. Decide in advance whether the business can tolerate reduced performance during a disaster or whether you must scale the secondary region up as part of the failover. If the latter, the scaling steps belong in the runbook with the capacity targets written down, because nobody should be guessing instance sizes during an incident.

Concurrent processing deserves specific thought. The concurrent managers carry batch work that may have been mid flight when the primary failed. Your runbook should state how in flight requests are handled after promotion, whether they are restarted, abandoned, or reconciled, so the business knows the state of its batch processing when the system comes back.

Validation that reflects real business use

Validating EBS recovery means more than confirming the database is open. It means logging in as a real user, opening the forms and pages that matter, running a representative transaction end to end, and confirming the result lands and is visible. Define a validation script that exercises the modules the business actually depends on, for example a financial posting or an order, so that when you declare the environment recovered you are speaking from evidence. A login screen that appears is not the same as a working ERP.

Build the validation script once with the business owners so it reflects what they care about, and run it during every DR test so it stays accurate as the environment changes. This is the difference between a recovery you can certify and one you are merely hopeful about.

Bringing in the right expertise

E Business Suite on OCI sits at the intersection of database, application, networking, and licensing, and few teams hold all of that in house. The architecture follows the patterns in the cross region DR guide, the database protection follows Data Guard on OCI, and the resilience underneath it follows fault domain design. Getting the licensing position of a standby EBS environment right is its own specialist topic, and treating it as an afterthought is far more expensive than planning it from the start. To plan or harden DR for your E Business Suite estate, book an OCI assessment and we will map the whole stack to the recovery objectives the business actually has.