Cross-Cloud Data Guard: 28 ms RTT and an RPO of 5 Minutes

No, SYNC is the wrong default here. In SYNC redo transport, a commit cannot return until the standby acknowledges redo. With 28 ms RTT, each commit pays at least one network round trip - roughly 28 ms - plus standby redo write and acknowledgement overhead. Under 5,000 active sessions, even a modest commit rate will queue, and the application owner's latency concern is justified.

Recommendation: Maximum Performance with ASYNC redo transport.

• 60 MB/s of redo is about 0.5 Gbps, well below the 10 Gbps interconnect. The standby can keep up, so transport lag should stay in seconds, not minutes.
• Set a transport-lag alarm at 2 minutes and a second at 4 minutes. If lag reaches 5 minutes, the RPO is at risk; the runbook should alert and, if necessary, throttle noncritical batch work.
• ASYNC does not guarantee RPO zero. If the regulator later demands zero data loss, the standby must be within a few milliseconds - same metro or same cloud region - not 28 ms away across clouds.

Document the accepted RPO as "up to 5 minutes, with alarm at 2 minutes" rather than claiming zero. Test the restore and failover path against the 30-minute RTO, including DNS propagation and application reconnect.

Primary path: Oracle Interconnect for Google Cloud, 10 Gbps, between the Google VPC and the OCI VCN. Advertise only the database and application subnets, not default routes. Data Guard uses TCPS on the redo port, with wallet-based encryption and a static listener registration on the standby.

Backup path: IPsec VPN over the internet, with the same TCPS encryption. It is for redo transport and management only; do not route application SQL over it unless the interconnect is down and the business accepts the latency.

Application connections:

• Use a TNS alias with a DNS CNAME and a low TTL, not hard-coded IP addresses.
• Applications in Google Cloud connect to the primary through private routing inside Google Cloud; applications in OCI connect through the interconnect.
• At failover, update the CNAME to the OCI SCAN endpoints, flush connection pools, and rely on application retry logic. Use Data Guard broker and Fast Application Notification where the driver supports it.
• Test MTU and fragmentation across the interconnect; keep 1500-byte MTU unless jumbo frames are proven end to end.

Security: No public database endpoints; security lists allow only application and DBA CIDRs; interconnect traffic is private but still encrypted at the database layer.

Observer placement: Put the Data Guard observer in a third failure domain that is not the primary Google Cloud region and not the OCI standby region. A small OCI region or an Azure region with low-latency private connectivity to both is acceptable. The observer must not run in either database's cloud region, or a regional outage can remove the tiebreaker.

Split-brain prevention:

• Use Data Guard broker with fast-start failover and a single observer.
• Configure FastStartFailoverThreshold so a transient 28 ms network blip does not trigger failover.
• The observer grants failover only when it can see the standby and has lost the primary; if it can see both, it does not fail over.
• Keep the standby read-only with Active Data Guard so no application writes can occur there before role transition.
• At failover, fence the old primary by revoking its network path or shutting it down before reopening it as a standby, then reinstate with Flashback Database.

Runbook: declare the disaster, confirm observer state, fail over, update DNS, validate application connectivity and redo apply in the reverse direction. If the observer itself is lost, do not perform a manual failover until the primary is confirmed down; otherwise both sites may accept writes.