Data Guard on Exadata Cloud

Backups protect you from data loss. Data Guard protects you from downtime. On Exadata Cloud Service the two are complementary, and the most common mistake we see is a team that has a solid backup strategy and assumes it gives them disaster recovery. It does not. If your recovery time objective is measured in minutes rather than hours, you need a standby database, and on ExaCS that means Oracle Data Guard.

This guide explains how Data Guard fits on Exadata Cloud Service, the choices that actually shape your recovery profile, and a reference topology you can adapt. It assumes you understand the platform basics covered in the complete guide to Exadata Cloud Service.

What Data Guard gives you

Data Guard maintains one or more standby databases that are continuous copies of your primary. Redo generated on the primary is shipped to the standby and applied there, so the standby is always close to current. If the primary fails, you switch over or fail over to the standby and resume service. The gap between primary and standby, and how fast you can switch, are the two numbers that define your disaster recovery posture.

On Exadata Cloud Service you typically place the standby in a second availability domain or, for true regional protection, a second region. The platform automates much of the provisioning through the OCI console and the database tooling, but the design decisions remain yours.

Protection modes and the durability tradeoff

Data Guard offers three protection modes, and choosing between them is really a choice about how much you will trade performance for zero data loss.

The practical rule: within a region, between availability domains, latency is low enough that synchronous transport in Maximum Availability mode is usually viable and gives you zero data loss. Across regions, the round trip latency makes synchronous transport a performance tax most workloads will not accept, so you run asynchronous in Maximum Performance mode and accept a small, bounded transport lag.

Active Data Guard

By default a standby is mounted but closed. Active Data Guard opens the standby read only while it continues to apply redo, which lets you offload reporting, read only application traffic and backups to the standby. That turns a standby that would otherwise sit idle into useful capacity. It is a licensed option, so confirm your entitlement before you design around it. For the licensing and Bring Your Own License implications, this is exactly the kind of decision worth checking with a licensing specialist before you commit.

Role transitions: switchover versus failover

There are two ways the standby becomes the primary. A switchover is a planned, graceful role reversal with no data loss, used for patching, maintenance and testing. A failover is an unplanned promotion of the standby after the primary is lost, and depending on your protection mode it may involve a small, bounded amount of data loss. You should rehearse both. A disaster recovery plan that has never been tested is a hope, not a plan.

Data Guard broker simplifies and automates these transitions, and Fast Start Failover can automate the failover decision entirely when the primary becomes unavailable, removing the human delay from your recovery time. Configure an observer in a third location so the failover decision is not made from inside either failing site.

A reference topology

This three way topology gives you fast automatic recovery from a local failure and a deliberate, tested path to a second region if you lose the first one entirely. Pair it with your backup strategy so backups cover the data loss scenarios Data Guard cannot, such as logical corruption that replicates to the standby.

Networking and security for the redo path

The redo transport between primary and standby crosses your network, so it needs a path and it needs protection. Within a region the VM clusters communicate over the cloud network. Across regions you use remote peering or a backbone connection. Either way, encrypt the redo in transit and scope the security lists so only the database nodes can talk on the transport ports. The details sit alongside the rest of your layout in Exadata networking and the controls in ExaCS security.

Where teams get this wrong

The recurring mistakes are predictable. Teams run async cross region and then claim zero data loss, which is not what async gives you. They build a standby and never test a switchover, so the first real failover is also the first rehearsal. They forget the observer, so Fast Start Failover cannot make an independent decision. And they assume Active Data Guard is included when it is a separate license. A short design review catches all four before they become an incident report.

If you want help sizing protection modes against your actual recovery objectives and network topology, the Exadata Cloud Service practice designs and tests Data Guard configurations as part of a fixed scope engagement.