Oracle EBS Disaster Recovery: Extending Resilience from On-Premises to OCI

 A structured walkthrough of designing a robust, secure, and cost-effective Disaster Recovery (DR) strategy for Oracle E-Business Suite (EBS) by extending an on-premises deployment to Oracle Cloud Infrastructure (OCI).

1. Introduction

For organizations running mission-critical workloads on Oracle E-Business Suite (EBS), an unplanned outage at the primary data center is not merely an IT inconvenience — it is a direct threat to financial close cycles, supply-chain operations, payroll, and customer-facing services. A well-engineered Disaster Recovery (DR) strategy is therefore non-negotiable.

Traditionally, EBS DR meant building and maintaining a second physical data center: duplicate servers, duplicate storage, duplicate licenses, and duplicate operational overhead. Oracle Cloud Infrastructure (OCI) changes that economic model. By treating OCI as the standby region, organizations gain Oracle-engineered performance for the database tier, on-demand compute for the application tier, and a pay-as-you-consume cost profile that aligns naturally with a passive DR posture.

This article presents an architectural blueprint and the associated operational best practices for implementing EBS DR between on-premises and OCI.

2. Choosing the Right DR Topology

The first design decision is the topology. It directly drives cost, recovery objectives (RTO/RPO), and operational complexity. EBS DR on OCI is most commonly deployed in an active-passive pattern, with two practical flavors:

Cold Standby

OCI infrastructure (compute, app tier file systems) is fully defined as code but only spun up during a failover event. Database may be replicated continuously, while application servers are provisioned on demand.

• Pros: Lowest steady-state cost.
• Cons: Higher RTO; bootstrap time required.

Warm Standby

Application tier nodes are continuously running (often at reduced capacity), and the database is kept in sync through Oracle Data Guard. The DR site can absorb traffic with minimal lead time.

• Pros: Low RTO; quick switchover.
• Cons: Higher continuous compute cost.

3. Database Tier — Oracle Data Guard to OCI

The single most important component of an EBS DR strategy is keeping the database tier synchronized. Oracle Data Guard (Physical Standby) is the recommended, Oracle-supported mechanism for replicating an on-premises EBS database to a standby database hosted on OCI.

• Real-time or near-real-time redo-stream replication from on-prem primary to OCI standby.
• Fast-Start Failover (FSFO) via the Data Guard Broker for automated role transitions.
• Snapshot Standby mode — convert the standby into a read-write database for DR rehearsals or QA without breaking the protection chain.
• Compatible with EBS-certified database editions on OCI: VM DB Systems, Bare Metal DB, or Exadata Database Service.

Sample Data Guard Broker Configuration

-- Verify protection mode and apply lag from primary
DGMGRL> SHOW CONFIGURATION;

Configuration - ebsdg_config
  Protection Mode: MaxAvailability
  Members:
  ebsprd - Primary database
    ebsoci - Physical standby database

Fast-Start Failover: ENABLED
Configuration Status: SUCCESS (status updated 12 seconds ago)

DGMGRL> SHOW DATABASE 'ebsoci';
  Transport Lag: 0 seconds (computed 1 second ago)
  Apply Lag: 0 seconds (computed 1 second ago)
  Apply Rate: 18.42 MByte/s

Tip: For EBS environments, ensure that the standby database carries the same character set (e.g., AR8MSWIN1256 or AL32UTF8), patch level, and time zone files as the primary. Mismatches surface during switchover, not during quiet operation.

4. Application Tier Synchronization

EBS is more than a database. The application tier carries patches, customizations, configuration files, concurrent program logic, and printer/profile definitions. These must be replicated alongside the database to keep the DR site usable.

Directory	Contents	Recommended Sync Mechanism
$APPL_TOP	Application product files, custom code, patch staging	rsync over SSH / GoldenGate file replication
$COMMON_TOP	Java classes, HTML, log/output directories, utilities	rsync with exclude rules for transient logs
$INST_TOP	Instance-specific configuration (regenerated by AutoConfig)	Snapshot + AutoConfig regeneration on DR boot
Custom binaries / printers	Site-specific scripts, drivers	Configuration management (Ansible / Chef)

Example rsync sync job (cron)

# /etc/cron.d/ebs_dr_sync — runs every 30 minutes
*/30 * * * * applmgr /usr/bin/rsync -azh --delete \
  --exclude 'logs/*' --exclude '*.tmp' \
  /u01/oracle/PROD/fs1/EBSapps/appl/ \
  ebsdr@oci-ebs-app01:/u01/oracle/PROD/fs1/EBSapps/appl/ \
  >> /var/log/ebs_dr_sync.log 2>&1

OCI tip: For larger EBS estates, pre-stage the application tier into OCI File Storage or OCI Object Storage. Object Storage is ideal for cold staging of patch repositories and full app-tier backups, while File Storage supports near-instant mount on freshly provisioned compute nodes.

5. Leveraging Native OCI Services for DR

OCI provides several first-class services that reduce custom scripting and improve recovery reliability. These should be treated as building blocks of the DR architecture, not optional add-ons.

Block Volume Backup

Policy-based, incremental backups of database and application disks; retainable in a separate region for added isolation.

Object Storage

Durable, eleven-nines storage tier for RMAN backups, archived redo, application snapshots, and DR runbook scripts.

OCI Vault

Centralized management of EBS APPS passwords, Wallet entries, and TLS certificates — encrypted with customer-managed keys.

DNS & Load Balancing

Health-check driven failover of user-facing URLs (e.g., ebs.company.com) toward the OCI listener during a declared DR event.

6. Automating Failover and Recovery

Manual DR is slow DR. Every step that can be codified should be codified, with version control and peer review.

• Terraform or OCI Resource Manager — declarative provisioning of VCNs, subnets, compute, block volumes, and load balancers.
• Ansible / Shell wrappers — orchestration of adstrtal.sh, adstpall.sh, listener startup, and AutoConfig regeneration.
• Oracle EBS Cloud Manager — for greenfield OCI EBS provisioning, lifecycle operations, and clone-from-backup workflows.
• OCI Monitoring + Notifications — automated alarms on Data Guard apply lag, block-volume backup failures, and listener availability.

Indicative DR Switchover Sequence

# 1. Stop on-prem application tier (if reachable)
$ adstpall.sh apps/<apps_pwd>

# 2. Perform Data Guard switchover to OCI standby
DGMGRL> SWITCHOVER TO 'ebsoci';

# 3. Provision / start the OCI EBS application tier
$ terraform apply -auto-approve -var "dr_state=active"

# 4. Reconfigure context file and run AutoConfig
$ adautocfg.sh

# 5. Start application tier services on OCI
$ adstrtal.sh apps/<apps_pwd>

# 6. Update DNS (or LBaaS backend set) to point users to OCI
$ oci dns record rrset update --domain ebs.company.com ...

7. DR Testing & Validation

A DR plan that has never been exercised is, by definition, untested. Build a recurring DR drill cadence into the operating calendar.

• Conduct a full or partial DR drill every 3–6 months.
• Use Snapshot Standby to validate application functionality without breaking the protection chain.
• Automate post-failover health checks: HTTP probes on Self-Service URL, Concurrent Manager status, key responsibilities, financial period close.
• Document and version each DR runbook; capture lessons learned in the next iteration.

-- Sample post-failover sanity check on the standby (now primary)
SQL> SELECT name, open_mode, database_role, db_unique_name
    FROM v$database;

NAME    OPEN_MODE     DATABASE_ROLE    DB_UNIQUE_NAME
-------- --------------- ---------------- ----------------
EBSPRD   READ WRITE     PRIMARY         ebsoci

8. Security & Compliance Considerations

Cross-site replication moves sensitive data — financials, HR, supplier records — across networks and between security domains. The DR design must therefore be hardened end-to-end.

• Encryption in transit: Use TCPS for Data Guard transport, IPSec/FastConnect for the underlying network, and TLS 1.2+ for application traffic.
• Encryption at rest: Enable Oracle Transparent Data Encryption (TDE) on both primary and standby, with master keys managed by OCI Vault.
• Network isolation: Dedicated VCN, segregated subnets for DB and app tier, and tightly scoped Security Lists / NSGs.
• Identity: IAM compartments and policies aligned with least privilege; separate operator vs. break-glass identities.
• Compliance: Map controls to applicable frameworks (e.g., business continuity policies, ISO 22301, and local regulatory mandates).

9. Cost Optimization for the DR Site

One of the strongest reasons to host EBS DR on OCI is the ability to right-size the standby footprint. A well-tuned DR site costs a fraction of a duplicated on-prem environment.

• Run the DR application tier on smaller flexible-shape VMs; scale up only when activated.
• Use scheduled start/stop for cold/warm DR application nodes during quiet hours.
• Tier old backups from Standard Object Storage to Archive Storage.
• Continuously monitor OCI cost reports and apply Budgets and Alerts at the compartment level.

10. Final Architectural Recommendations

• Adopt Data Guard as the canonical replication technology for the EBS database.
• Use a combination of rsync, Object Storage, and AutoConfig to keep the application tier consistent and re-deployable.
• Maintain multinode consistency between primary and DR: same patch level, same character set, same time zone files, same custom code.
• Automate everything reasonable using Cloud Manager, Terraform, Ansible, and OCI-native tooling.
• Test, retest, and rehearse — DR readiness is a continuous program, not a one-off project.

11. Conclusion

Adopting Oracle Cloud Infrastructure as the Disaster Recovery site for Oracle E-Business Suite delivers more than redundancy — it reshapes the economics and the operating model of business continuity. OCI is a secure, high-performance, enterprise-grade platform that is purpose-engineered for Oracle workloads, which means EBS runs on a cloud foundation that already understands its database, storage, and networking demands.

By extending an on-premises EBS environment to OCI for DR, organizations can retire the cost and operational drag of fully mirrored physical data centers. Native services such as Oracle Data Guard for real-time database replication, Object Storage for durable backup, Vault for secret protection, and Cloud Manager / Resource Manager for automated provisioning combine to make DR processes faster, more repeatable, and substantially cheaper to maintain.

OCI's globally distributed regions, robust networking backbone, and integrated security services further ensure low-latency access and high availability — translating directly into rapid failover and minimal downtime when an incident occurs. In other words, OCI does not merely serve as a cost-effective standby site; it positions the enterprise on a strategic platform for long-term digital transformation and cloud readiness, while raising the resilience bar of the most business-critical Oracle workload an organization typically runs.

Thanks for reading.
BR,
Zaheer
Techvisions — Cloud & Infrastructure Practice