Retail ERP Exit: Database@Azure vs OCI vs Azure VMs
Northwind Retail runs Oracle E-Business Suite 12.2 on a four-node Exadata X8 half rack in a Chicago data center. The 48 TB production database supports 8,000 concurrent order-entry users at peak and a nightly close batch that must finish within four hours. The customer-facing order portal is a .NET application in Azure East US 2, and the integration layer is Azure Service Bus. The board has committed to exiting the Chicago data center in 14 months. The Oracle estate is licensed at 64 OCPUs with BYOL and has 18 months of remaining support. The architecture team is debating three options: Oracle Database on Azure VMs, Oracle Database@Azure, or keeping the database in OCI and connecting to Azure. The application team measured 38 ms round-trip latency from Azure East US 2 to the Chicago data center and says anything above 3 ms for checkout calls is unacceptable. Security requires private connectivity and customer-managed keys. Finance wants a single Azure invoice where possible.
1. Which target architecture should the team commit to, and what two quantitative gates must be passed before signing the 14-month plan? Show the reasoning, including why the other two options lose.
Read the worked answer
Decision: Oracle Database@Azure in the same Azure region as the portal.
- The binding constraint is the 3 ms checkout budget. Database@Azure places Exadata in an Azure region and attaches it to a delegated subnet in the customer VNet, so application-to-database traffic stays inside Azure's regional network. A pilot should show sub-millisecond to low-single-digit-millisecond p95, not the 38 ms Chicago round trip.
- OCI plus Oracle Interconnect for Azure is a strong multicloud pattern, but it loses on latency: even a nearby OCI region adds cross-cloud RTT and a second operational hop. An OCI region in Chicago would still not share the same fault domain as East US 2, and the checkout path would span providers.
- Oracle on Azure VMs can meet latency but gives up Exadata offload, RAC/Data Guard automation, and Oracle-managed infrastructure; the team would own patching, backup, and HA design.
Two gates before commitment:
- A load test from the portal subnet to the database SCAN endpoints at peak concurrency, with p95 < 3 ms and p99 < 10 ms; also prove the four-hour batch completes with headroom.
- Confirm service availability, Exadata quota, and 64-OCPU BYOL acceptance in the target Azure region. If the service is only available in a paired region, re-measure latency and re-run the business case before signing.
2. The CIO asks what remains in OCI and how to avoid two disconnected operating models. Describe the control-plane, identity, billing, and support split.
Read the worked answer
Control plane: The OCI tenancy remains because Database@Azure is provisioned and operated through Oracle Cloud Infrastructure control-plane APIs. OCI owns Exadata infrastructure lifecycle, Data Guard broker configuration, backup policy, and OCI IAM policies for DBAs. Azure owns the delegated subnet, NSGs, private DNS, and Azure Monitor alerts. This split is unavoidable, so publish one service catalog and one runbook per database rather than letting each team invent its own process.
Identity: Federate the OCI identity domain to Microsoft Entra ID with SAML and SCIM. Do not create local OCI users for daily administration. Azure RBAC controls the Azure resource group; OCI IAM groups control database and Exadata actions. Use the same Entra group names in both clouds so access reviews are comparable.
Billing: Database@Azure is purchased through Azure Marketplace, so the infrastructure charge lands on the Azure invoice and can consume Azure committed spend where the agreement allows. Tag every Azure resource and mirror the tags in OCI. Reconcile monthly because marketplace line items do not always carry all resource tags.
Support: Azure support handles Azure networking and identity tickets; Oracle support handles database and Exadata tickets. Define a joint escalation path for cross-plane incidents, such as a subnet change that breaks database connectivity.
3. What is the largest resilience gap in the chosen design, and what would you add without doubling cost?
Read the worked answer
Largest gap: the design is single-region in Azure. A regional Azure outage takes down both the portal and the database, and the 14-month exit plan does not by itself create a second failure domain.
Add a Data Guard standby in a second Azure region or in OCI, sized for the required RTO rather than for peak production. A smaller standby is acceptable for disaster recovery if it can be scaled at failover and if the runbook proves the scale-up step. If the standby is in OCI, use Oracle Interconnect for Azure for private redo transport and keep the application failover path in DNS with a low TTL.
Also add an immutable backup copy in a different cloud or region, with restore tests, and a documented reverse-synchronization path for fallback. This avoids the common failure mode where the standby exists but has never been opened read-write or tested with the application connection strings.