Uno dei principali ostacoli all’implementazione di un piano di Disaster Recovery è il costo dei beni inattivi, un investimento infruttuoso che provoca sempre qualche turbamento. Il consueto approccio al Disaster Recovery prevede la duplicazione delle risorse critiche, la replicazione dei dati ed un insieme di procedure di gestione e controllo del piano di attività da attuare a seguito dell’evento critico. Per definizione le risorse duplicate rimangono inattive in attesa dell’evento,  il loro costo va ad appesantire il budget IT in modo più o meno equivalente ai costi del sito primario; molto dipende dagli obiettivi del piano (Recovery Point – RPO e Recovery Time – RTO)  e  da quanta parte del sistema informativo debba essere ripristinato e sostenuto dal sito secondario.  E’ benvenuta, quindi, qualsiasi operazione che possa trasformare  i beni inattivi in strumenti operativi a supporto del business quotidiano incrementando il ROI del progetto di Disaster Recovery.

Nel caso dei servizi di database l’implementazione di una infrastruttura di replicazione dati basata sull’invio dei  registri (logs) delle transazioni rientra in questa casistica; oltre a diminuire i consumi di banda di trasmissione (network bandwidth) una infrastruttura che implementi un database in standby permette di sfruttare il database secondario anche per altri usi quali, ad esempio,  il test delle applicazioni su dati reali, il reporting ed il backup. Tutti i principali gestori di banche dati fornisco una tecnologia integrata  di replicazione; per questo esempio useremo come riferimento un sito Oracle basato su DataGuard.

Oracle Dataguard in breve

DataGuard è la soluzione di ripristino di emergenza di Oracle; implementa un servizio di alta disponibilità e di protezione dei dati in caso di caduta di un sito Oracle. Contemporaneamente  al database primario vengono mantenuti uno o più database di standby distribuiti in uno o più siti remoti ; gli standby sono sincronizzati con il database primario mediante la spedizione dei file di Redo (registro delle transazioni di aggiornamento di un database). Gli utenti connessi al primario possono avere loro sessioni  redirette in modo trasparente al sito secondario in caso di caduta del sito. La trasmissione dei Redo Logs dal sito primario ai siti di standby è relativamente economica e permette di implementare una soluzione di protezione di dati affidabile e popolare.

Fino alla versione 9i di Oracle la spedizione dei logs veniva fatta  dal processo ARC operante sul database primario ad ogni riempimento dei files;  in tal modo la sincronizzazione dei database poteva essere solo differita. Dalla 9i  è lo stesso processo di scrittura dei log LGWR che spedisce le note di Redo non appena create. Questo permette di alzare il livello di protezione dei dati fino ad ottenere una sincronizzazione in tempo reale. I dati ricevuti dal sito primario vengono scritti dal processo RFS in Redo Logs appositi sul sito secondario ed applicati, opzionalmente,  in tempo reale al database secondario.  

I database in standby possono essere di tipo fisico o logico. Gli standby di tipo fisico sono una copia esatta del database primario; la copia avviene blocco per blocco. Per gli standby di tipo logico la sincronizzazione si basa sulla tecnologia LOGMINER che ricostruisce le istruzioni DML Sql dalle note di Redo e le usa per aggiornare i database che, pertanto, possono anche contenere schemi diversi. Per semplicità di configurazione e gestione nelle implementazioni per un Disaster Recovery è suggerito l’uso di database in standby fisico.

Le modalità di sincronizzazione sono tre:

• Maximum Performance:  i logs vengono spediti al sito di standby in modo asincrono rispetto alla transazione di aggiornamento del database primario svincolando in tal modo le prestazioni del sito primario da quelle del supporto di trasmissione tra i siti; la sincronizzazione completa  tra i siti in questa modalità non può essere garantita. In caso di indisponibilità del sito secondario i logs vengono accumulati sul primario e spediti non appena si ristabiliscono le comunicazioni.
• Maximum Protection:  garantisce il massimo livello di sincronizzazione tra i siti (RPO=0). In questa modalità non viene confermata alcuna transazione sul sito primario fino a quando non sia stata ricevuta la conferma che le corrispondenti note di Redo siano state ricevute dal database secondario e scritte sui Redo di standby. Se questa conferma non viene ricevuta il sito primario viene bloccato impedendo che i contenuti primari e secondari divergano. Questa modalità risente fortemente dei tempi di latenza delle rete che collega i siti.
• Maximum Availability: è una modalità ibrida. Quando i siti primario e secondario sono in collegamento la sincronizzazione avviene in modalità Maximum Protection. In caso di indisponibilità del sito secondario i logs vengono accumulati sul primario e spediti non appena si ristabiliscono le comunicazioni; i logs vengono spediti in modo asincrono fino al completo riallineamento dei siti quando viene anche ripristinata la modalità Maximum Protection.

Una funzione interessante  di DataGuard 11g  è la possibilità di convertire un database di standby in un database di test mentre il sito secondario continua a ricevere i Redo log dal sito primario.  Terminato il test si ritorna il database nello stato di standby riabilitando l’eventuale applicazione in tempo reale dei logs; in caso di caduta del primario mentre è in corso un test il passaggio sul secondario (failover)  richiederà  probabilmente più tempo per la necessità di attendere il completamento dell’applicazione dei log accumulati.