Order-Matching Latency and AZ Failure on Exadata Database Service
A brokerage runs its order-matching platform in AWS us-east-1. Sixty application servers are spread evenly across three Availability Zones and currently call Oracle 19c on EC2. The database is 18 TB, peaks at 70,000 IOPS and 6,000 sessions, and has a p99 commit latency of 1.8 ms. The firm is moving to Oracle Database@AWS Exadata Database Service. Compliance requires RPO 0 and RTO of 10 minutes or less for an AZ failure. A reporting team runs heavy ad-hoc queries and must not affect order matching. The latency budget from application to database is 2 ms. The proposed design puts one Exadata infrastructure in a single AZ, a standby in a second AZ, and lets all application servers call the primary across AZ boundaries. The team also plans to use the standby for reporting. You must review the design before provisioning. The primary AZ hosts most application traffic, but the other two AZs still carry 35% of peak sessions.
1. Recommend the database topology, AZ placement, and reporting-access pattern. Explain the trade-offs that drive your choice.
Read the worked answer
Recommendation. Use a multi-AZ Exadata Database Service topology with a primary and a Data Guard standby in a different AZ. Keep the primary and the majority of application servers in the same AZ; route local traffic within that AZ and use cross-AZ calls only for failover, not for every commit. RPO 0 requires synchronous redo transport, which adds round-trip latency; placing the standby in a nearby AZ keeps that penalty inside the 2 ms budget. Do not put reporting on the primary: enable Active Data Guard read-only on the standby, or use a separate read-only clone if the service option is available, and cap reporting with resource manager. A single-AZ primary without a standby cannot meet RTO 10 for AZ failure. Using the standby for reporting is acceptable only with Active Data Guard and sufficient standby capacity; otherwise reporting can delay apply and increase RPO. Validate with a real 6,000-session workload, not synthetic IOPS.
2. Design private connectivity and client failover. What should the application use, and what should it avoid?
Read the worked answer
Connectivity. Place the Oracle Database@AWS network and the application VPC on a private path with non-overlapping CIDRs; no public database endpoint. Use Oracle Net connect strings with multiple SCAN addresses or a global service, FAN events, and fast connection failover in the pool for Java, .NET, or the equivalent driver. Do not rely on a single DNS A record with a long TTL; DNS can be a secondary steering mechanism, but Oracle-driven role transition and FAN should drive reconnects. Set local AZ preference so the 20 servers in the primary AZ connect locally; the other 40 use the same private path and fail over on event. Configure retry and backoff for the 10-minute RTO, and test planned switchover plus unplanned failover. Avoid connecting reporting and OLTP through the same service without consumer groups; use services to isolate workloads.
3. Choose a migration method from EC2-based 19c to Oracle Database@AWS Exadata and define cutover gates.
Read the worked answer
Method. Because source and target are both 19c, use a physical migration: Data Guard standby or Zero Downtime Migration with Data Guard, not a logical unload for 18 TB. Build the standby over private connectivity, let it catch up, then run a real workload replay and compare p99 commit latency, IOPS, and plan stability. For cutover, stop application writes, confirm apply lag is zero, switch over, run smoke tests, and keep the source intact for rollback. If Data Guard is not feasible because of version or platform limits, use GoldenGate for change capture after an RMAN or Data Pump initial load. Gate criteria: RPO 0 verified, RTO rehearsal under 10 minutes, reporting isolated on Active Data Guard, and no cross-AZ commit path for the 20 local application servers.