Oracle · Software · scheda YoctoIT

Data Guard

Le standby geografiche: RPO zero, failover misurati e repliche che lavorano — il DR del database fatto come si deve.

FOCUS · IL PIANO B DEL DATOStandby sincrone e failover provati: il disastro come procedura, non come dramma
Richiedi il Free Assessment Scopri di più
Materiale YoctoIT per clienti e partner · Oracle, Exadata, GoldenGate e gli altri prodotti citati sono marchi di Oracle Corporation e/o sue affiliate.
01 · Cos'è

Active Data Guard, in chiaro.

Data Guard mantiene copie standby del database allineate via redo: sincrone per RPO zero, asincrone sulla distanza. Active Data Guard le rende utili anche da vive — report e backup girano sulla standby. Il failover (anche automatico con l'observer) è questione di secondi. Se lo si prova.

RPO 0
con la replica sincrona: nemmeno una transazione persa
<60 s
il failover con fast-start: il disastro dura un caffè
Standby utile
report, backup e query sulla replica: il DR che lavora
Active Data Guard
VESTE UFFICIALE ORACLE · DATA GUARD
ARCHITETTURA UFFICIALE · DATA GUARD · FONTE: ORACLE DOCS
ARCHITETTURA UFFICIALE · DATA GUARD · FONTE: ORACLE DOCS
02 · Come lo si usa bene

Le cose che fanno la differenza.

La catena

Produzione (primary)dove il dato nasce
Standby sync · campus
Standby async · geo
Snapshot standby
zero perdita · distanza · test
Broker + observerfailover orchestrato, anche automatico
Switchover di prova periodicil'evidenza che funziona
Il redo viaggia, la continuità pure

Topologia per obiettivi

RPO/RTO dichiarati → sync qui, async là: l'architettura discende dai numeri, non viceversa.

Protezione dal logico

Flashback e ritardo applicato: anche l'errore umano e il ransomware nel modello.

Switchover di manutenzione

I grandi lavori si fanno sulla ex-standby: il downtime pianificato tende a zero.

Prove con verbale

Due volte l'anno, failover vero e documentato: per NIS2 e per la serenità.

03 · In profondità

Protezione, offload e fast-start failover

Active Data Guard replica il redo in tempo reale verso standby locali e remote: le modalità (Max Protection/Availability/Performance) scelgono il compromesso RPO/latenza; lo standby aperto in read-only assorbe report e backup (redo apply continuo), il Far Sync consente RPO zero anche a distanza, il fast-start failover con observer promuove da solo in secondi, l'Application Continuity ripete le transazioni in corso: l'utente non vede il failover.

  • Max Availability — RPO zero sincrono con tolleranza: il set-up che consigliamo in metro
  • Real-time query — lo standby che lavora: report, backup e query offloadate
  • Far Sync — l'inoltro sincrono leggero: RPO zero anche verso la region lontana
  • FSFO + observer — failover automatico in secondi, senza umani nel percorso
  • Application Continuity — le transazioni in volo ripetute: il failover invisibile all'app
  • DML redirection — scritture occasionali sullo standby: reindirizzate al primario
04 · Numeri e ciclo di vita

I numeri che contano.

RPO 0
con Max Availability/Protection e Far Sync
<30 s
il failover automatico tipico con FSFO
2+
standby per primario: locale + remota
100%
del redo validato: la corruzione non si propaga
Il DR si giudica alle prove: switchover programmati due volte l'anno, observer presidiato e run-book — la continuità con le evidenze.
05 · Use case

Dove rende davvero.

DR geografico

Il secondo sito (o il cloud) sempre allineato.

Migrazioni senza fermo

La standby diventa il nuovo primario: cutover in minuti.

Offload di produzione

Report pesanti e backup fuori dal primario.

Un DR non provato è una speranza: i nostri switchover hanno il verbale.