Data Guard on OCI Explained

When people talk about Oracle disaster recovery, they are usually talking about Data Guard whether they name it or not. It is the technology that keeps a synchronised copy of an Oracle Database running somewhere else, ready to take over when the primary fails. On Oracle Cloud Infrastructure, Data Guard is a first class capability that you can enable on database systems with a few decisions rather than weeks of bespoke engineering. The trouble is that those few decisions, protection mode, standby placement, and failover behaviour, are exactly the ones that determine whether your DR actually meets the recovery targets the business expects. This article explains how Data Guard works on OCI and how to make those decisions deliberately.

What Data Guard does

Data Guard maintains one or more standby databases that are kept in sync with a primary database by shipping and applying redo, the stream of changes the database generates. If the primary fails, a standby can take over the primary role, either through a manual switchover for planned events or an automatic or manual failover for unplanned ones. Because the standby is a real, mounted or open database rather than a restored backup, the recovery is measured in minutes, not hours, and the data loss can be brought close to zero depending on how the redo is transported. This is the fundamental difference between Data Guard and backup based recovery: the standby is always there, always current, and always ready.

Protection modes and the tradeoff they encode

Data Guard offers three protection modes, and choosing among them is really choosing where you sit on the tradeoff between data loss and performance. The mode controls how redo is transported and whether the primary waits for the standby to acknowledge it.

Most OCI deployments use Maximum Performance, because asynchronous transport adds no latency to the primary and the data loss exposure is tiny in practice. Maximum Availability suits workloads that genuinely cannot lose committed transactions, accepting a small latency cost. Maximum Protection is reserved for the rare case where the primary should rather stop than risk any data loss at all. The right choice flows directly from the recovery point objective, which is why setting that target first, as described in RTO and RPO planning for OCI, matters so much.

Where to place the standby

On OCI you can place a standby in the same availability domain, a different availability domain in the same region, or a different region entirely, and each placement protects against a different scale of failure. A standby in another availability domain protects against the loss of a data centre while keeping latency low. A standby in another region protects against the loss of an entire region but introduces distance, which usually pushes you toward asynchronous transport. Many serious designs use both: a local standby for high availability and a remote standby for disaster recovery, giving fast protection against common failures and durable protection against regional loss. The regional placement question is explored further in cross region DR on OCI.

Switchover and failover behaviour

Data Guard supports planned switchovers, where the primary and standby roles are swapped cleanly with no data loss, and failovers, where a standby is promoted because the primary is gone. Switchover is the friendly path used for testing, patching, and planned maintenance, and it is fully reversible. Failover is the emergency path. You can configure failover to be observed and automated through Data Guard's fast start failover, which promotes a standby automatically when the primary becomes unavailable and an observer agrees, removing the human delay from the most time critical moment. Whether to automate failover is a judgement call that balances faster recovery against the risk of an unnecessary failover, and it should be decided per workload.

The observer and split brain

Fast start failover relies on an observer, an independent process that watches both the primary and the standby and breaks ties about who is in charge. Placing the observer correctly, in a third location independent of both database sites, is what prevents a split brain where two databases both believe they are primary. Getting this topology right is a detail that separates a reliable automated failover from a dangerous one.

Data Guard across the OCI database family

How you consume Data Guard depends on which database service you run. On Base Database and Exadata Database Service, Data Guard is configured at the database system level and gives you full control over modes and placement. On Autonomous Database, the equivalent protection is provided through Autonomous Data Guard, which is largely managed for you and enabled with a simple choice rather than detailed configuration. The principles are the same across all of them, a synchronised standby ready to take over, but the amount of configuration you handle yourself decreases as you move toward the more managed services. The broader database resilience picture is covered in high availability for Oracle Database on OCI.

A decision framework for Data Guard on OCI

Common mistakes

The recurring errors with Data Guard are not about the technology, they are about assumptions. Teams enable a standby and never test the switchover, so the day they need a failover is the first time the path has ever run. Teams choose Maximum Protection by instinct because it sounds safest, then are surprised when the primary halts during a network blip. Teams place a remote standby and forget that the application tier in the remote region also needs to be ready, which is the gap that OCI full stack disaster recovery closes. And teams let the standby fall behind without monitoring the apply lag, so the recovery point quietly drifts away from the target. Each of these is avoidable with deliberate design and regular testing.

Bringing it together

Data Guard is the heart of Oracle disaster recovery on OCI, and using it well comes down to a handful of deliberate choices driven by the business targets. Set the recovery point objective, pick the protection mode that meets it, place the standby for the failures you need to survive, and test the switchover until the failover holds no surprises. Continue with cross region DR on OCI, high availability for Oracle Database on OCI, and DR testing on OCI, and return to the disaster recovery pillar for how it all fits together. Our disaster recovery and HA practice designs and operates Data Guard configurations matched to real recovery targets.