Oracle · Software · YoctoIT tech page

Data Guard

The geographic standbys: zero RPO, measured failovers and replicas that work — database DR done the way it should be.

FOCUS · THE DATA'S PLAN BSynchronous standbys and rehearsed failovers: disaster as a procedure, not a drama
YoctoIT material for clients and partners · Oracle, Exadata, GoldenGate and the other products mentioned are trademarks of Oracle Corporation and/or its affiliates.
01 · What it is

Active Data Guard, made clear.

Data Guard keeps standby copies of the database aligned via redo: synchronous for zero RPO, asynchronous over distance. Active Data Guard makes them useful while alive — reports and backups run on the standby. Failover (automatic too, with the observer) is a matter of seconds. If you rehearse it.

RPO 0
with synchronous replication: not even one transaction lost
<60 s
failover with fast-start: the disaster lasts a coffee
A useful standby
reports, backups and queries on the replica: the DR that works
Active Data Guard
OFFICIAL ORACLE BRANDING · DATA GUARD
ARCHITETTURA UFFICIALE · DATA GUARD · FONTE: ORACLE DOCS
OFFICIAL ARCHITECTURE · DATA GUARD · SOURCE: ORACLE DOCS
02 · How to use it well

The things that make the difference.

The chain

Production (primary)where the data is born
Sync standby · campus
Async standby · geo
Snapshot standby
zero loss · distance · testing
Broker + observerfailover orchestrated, automatic too
Periodic trial switchoversthe evidence that it works
The redo travels, so does continuity

Topology by objectives

Declared RPO/RTO → sync here, async there: the architecture descends from the numbers, not the other way around.

Protection from logical errors

Flashback and applied delay: human error and ransomware in the model too.

Maintenance switchovers

The big works are done on the ex-standby: planned downtime tends to zero.

Rehearsals with minutes

Twice a year, a real, documented failover: for NIS2 and for peace of mind.

03 · In depth

Protection, offload and fast-start failover

Active Data Guard replicates the redo in real time to local and remote standbys: the modes (Max Protection/Availability/Performance) choose the RPO/latency compromise; the read-only open standby absorbs reports and backups (continuous redo apply), Far Sync allows zero RPO even over distance, fast-start failover with the observer promotes on its own in seconds, Application Continuity replays in-flight transactions: the user doesn't see the failover.

  • Max Availability — synchronous zero RPO with tolerance: the setup we recommend in metro
  • Real-time query — the standby that works: reports, backups and queries offloaded
  • Far Sync — the lightweight synchronous relay: zero RPO even to the far region
  • FSFO + observer — automatic failover in seconds, no humans in the path
  • Application Continuity — in-flight transactions replayed: the failover invisible to the app
  • DML redirection — occasional writes on the standby: redirected to the primary
04 · Numbers and lifecycle

The numbers that matter.

RPO 0
with Max Availability/Protection and Far Sync
<30 s
the typical automatic failover with FSFO
2+
standbys per primary: local + remote
100%
of the redo validated: corruption doesn't propagate
DR is judged at the rehearsals: switchovers scheduled twice a year, a watched observer and run-books — continuity with evidence.
05 · Use cases

Where it really pays off.

Geographic DR

The second site (or the cloud) always aligned.

Zero-downtime migrations

The standby becomes the new primary: cutover in minutes.

Production offload

Heavy reports and backups off the primary.

An untested DR is a hope: our switchovers come with minutes.