Multi-Region DR Claim with Batch-Driven Replication Lag
A SaaS provider runs a customer-facing analytics product on Oracle Database@AWS in us-east-1, with a disaster-recovery site in us-west-2. The primary is 6 TB, serves 4,000 sessions, and must meet 99.99% availability, RPO 5 minutes, and RTO 30 minutes. The application is active-active behind AWS Global Accelerator, but the database is active-passive with Data Guard asynchronous replication. In the last DR test, Global Accelerator failed over in 40 seconds, but application DNS took 22 minutes because the private hosted zone record had a 300-second TTL and connection pools cached the old address. Data Guard lag reached 12 minutes during the nightly batch. The provider wants to claim the DR target in its customer contract. You must fix the design and the test plan before the next audit.
1. Is active-passive Data Guard sufficient? What changes are needed to meet RPO 5 and RTO 30?
Read the worked answer
Assessment. Active-passive Data Guard can meet the target if replication lag and failover are engineered, but the current design does not. Asynchronous Data Guard cannot guarantee RPO 5 during a 12-minute batch lag; either throttle or isolate the batch, increase network bandwidth, or use a replication method that keeps change apply within 5 minutes. Measure lag by apply time, not by archive log count. For RTO 30, automate role transition with Data Guard broker and fast-start failover where supported, and pre-stage application configuration. Do not rely on Global Accelerator alone: it routes to the AWS Region, not to the database. The database endpoint must be switched by Oracle-driven failover with a short-TTL DNS or a global database service. Test an unplanned failover during batch, not only a quiet switchover.
2. Fix the application connection and DNS behavior.
Read the worked answer
Connection fix. Reduce the private hosted zone TTL to 30 seconds or less for the database alias, but do not make DNS the primary failover mechanism. Use Oracle Net with multiple addresses or a global service, FAN, and fast connection failover so pools evict dead connections. Configure connection pool maximum lifetime and validation so cached addresses expire. Global Accelerator should route users to a healthy application stack; the application stack then connects privately to the active database. Pre-create the DR application stack and test with the same connection strings. Avoid 300-second TTLs and infinite pool lifetimes; they turn a 1-minute database failover into a 22-minute outage. Document the retry and backoff behavior for the 30-minute RTO.
3. Define the DR test and the contractual evidence.
Read the worked answer
Test plan. Run quarterly tests that include an unplanned failover during the batch, with lag injected; measurement of RPO from the last committed transaction to the promoted database; measurement of RTO from failure injection to first successful customer transaction; and application reconnect without manual DNS edits. Capture timelines, lag graphs, error rates, and Data Guard broker logs. Include a rollback test. For the customer contract, state the measured RPO and RTO and the test cadence, not a theoretical capability. If the batch cannot be throttled, either exclude batch RPO from the claim or add capacity. Have Oracle and AWS support contacts and escalation paths in the runbook. An audit needs evidence of a failed test and remediation, not only a passed test.