PTDR Disaster Recovery for oracle database
INTRODUZIONE... 3 INTRODUZIONE... 3 I MECCANISMI BASE DI ORACLE DATA GUARD... 3 COSA SONO I REDO LOG?... 4 IMPATTO SULL'ARCHITETTURA COMPLESSIVA... 4 CONCLUSIONI... 5 L ALTERNATIVA A DATA GUARD: PTDR... 5 VANTAGGI DELLO STANDBY DATABASE REALIZZATO TRAMITE PTDR... 6
Introduzione Quando si sviluppa una applicazione spesso ci si concentra sulle prestazioni e sulla minimizzazione degli errori, ma quando l applicazione funziona in produzione è necessario considerare anche il grado di continuità di servizio che si riesce a garantire. Esiste una serie di ambiti in cui le applicazioni sono mission critical, ovvero il cui funzionamento continuo è di fondamentale importanza. Si pensi ad un web store di grosse dimensioni come Amazon o ad un sistema di gestione/scambio di titoli finanziari, la mancata possibilità di inserire o recuperare dati può avere conseguenze molto gravi sia dal punto di vista finanziario che dal punto di vista di perdita dei clienti. Il database Oracle consente tramite l'opzione Data Guard di realizzare una serie di soluzioni che consentono di bilanciare in maniera efficace sia le prestazioni che la disponibilità e l'integrità dei dati. Necessariamente non sarà semplicemente l utilizzo di questa opzione a garantire il superamento delle problematiche di continuità del servizio ma sarà la corretta implementazione di un insieme di procedure che sfrutteranno le funzionalità Oracle per ottenere questi obiettivi. Data Guard è una funzionalità che una volta implementata opera in modo automatico gestita dal data base principale che aggiorna di sua iniziativa i vari data base secondari sfruttando una complessa architettura. A fronte dei notevoli vantaggi che questa soluzione offre si introducono diversi vincoli architetturale e si carica il data base principale, che generalmente è la risorsa più delicata anche dal punto di vista delle performances, di attività relative alla distribuzione delle informazioni agli altri DB. Per questo abbiamo realizzato una soluzione alternativa, in gran parte simile a Data Guard in quanto utilizza gli stessi strumenti e le stesse funzioni standard Oracle, ma che toglie al DB principale la gestione della struttura di recovery demandandola ai Data Base secondari. In questo modo si semplifica enormemente la gestione delle eventuali anomalie ed errori che possono verificarsi nella gestione delle emergenze, rendendo più semplice e quindi efficace l utilizzo del DB di recovery. I meccanismi base di Oracle Data Guard Oracle Data Guard consiste nella definizione di un gruppo di database identici, uno dei quali ha il ruolo di primario, tutti gli altri sono definiti standby e sono delle repliche del primario. Il numero massimo di standby database per un singolo primario è 10. I database standby possono essere aggiunti anche "a caldo", ovvero durante il normale funzionamento operativo, in un momento successivo alla messa in esercizio, l'unico requisito richiesto è che il database operi in modalità archivelog mode (che dovrebbe essere, tranne rarissime eccezioni, l'unica modalità in cui operano i database Oracle in produzione). Oracle Data Guard consente di propagare le modifiche dal database primario agli standby secondo vari criteri, a seconda del compromesso prestazioni/affidabilità che si vuole ottenere. Il meccanismo di replica dei dati avviene tramite la propagazione dei redo/archive log.
Cosa sono i redo log? Sono dei file nei quali Oracle scrive tutte le modifiche effettuate ai dati; semplificando si può pensare che i redo log contengono le differenze fra uno stato del database ed uno successivo. Quando si esegue una transazione all'atto del commit (conclusione positiva) Oracle scrive le modifiche effettuate nei redolog e appena scritte queste informazioni restituisce il controllo alla procedura chiamante; i dati veri e propri (non solo le differenze) vengono scritti sui files del database vero e proprio in seguito, in modalità asincrona rispetto alle procedure utente per favorire le performances. Poiché in sistemi altamente transazionali i database sono continuamente soggetti a richieste di inserimenti, modifiche e cancellazioni i redolog tendono a riempirsi piuttosto velocemente; esiste un meccanismo di rotazione degli stessi, ovvero Oracle ne richiede un minimo di due e scrive sul primo; una volta che questo risulta pieno (la loro dimensione è fissa) si passa al successivo e così via fino al riempimento di tutti quelli disponibili. Quando anche l'ultimo redo log è stato riempito si passa riutilizzare il primo, previa verifica che le modifiche in esso contenute siano già state riportate sui file dati del database. Vi sono diverse cautele da utilizzare perché se si perde per qualsiasi motivo un redolog si perdono tutte le modifiche in esso contenute e con esse la possibilità di ripristinare il database Oracle a fronte di un eventuale crash del sistema. Per evitare simili epiloghi è consigliabile attivare le funzioni Oracle denominate archive log che consentono la duplicazione dei redolog e la loro archiviazione. G li archive log, infatti, non sono altro che le copie dei redolog salvati in un'altra posizione (directory/tape) dello storage in accumulo, sempre in accodamento uno dopo l altro ed utilizzabili ai fini del Disaster Recovery. Propagando i redo/archive log (ovvero solo i dati strettamente modificati) da un database ad un altro, anche geograficamente distanti, Data Guard riesce a mantenere delle repliche sempre sincronizzate. Impatto sull'architettura complessiva Oracle Data Guard non richiede cambiamenti o particolari accorgimenti nel codice applicativo; il suo funzionamento è completamente database-side e trasparente alle applicazioni che accedono ai dati. L'aspetto più importante da considerare è quello dell'architettura hardware e di rete necessaria per essere sicuri di limitare al minimo la perdita di dati; se si collocano i server in zone geografiche distanti è necessario assicurarsi che l'infrastruttura di rete sia affidabile al fine di evitare fermi operativi perché non si riescono a trasferire i log. La collocazione in locali distinti è, quando possibile, sempre consigliabile in quanto si evita che un danno strutturale (che può andare dalla mancanza di corrente, all'indisponibilità della rete fino all'incendio) possa coinvolgere sia il primario che gli standby; La soluzione Data Guard richiede la versione Enterprise di Oracle.
Conclusioni Oracle Data Guard è un meccanismo standard del database che consente, in funzione della quantità di dati che (non) si vogliono perdere, di costruire soluzioni veloci e affidabili. La sua implementazione non richiede modifiche alla struttura della base dati e non richiede modifiche al codice applicativo. Può essere implementata ed attivata anche ad applicativi funzionanti e già in produzione. Una sua corretta applicazione richiede una attenta valutazione della collocazione dei server e delle architetture ed infrastrutture di rete. L alternativa a Data Guard: PTDR Oracle è un prodotto estremamente valido e sofisticato, la soluzione che implementa con Data Guard è ottima per tutte le grandi realtà che dispongono, oltre che del prodotto Oracle anche di tutti i processi e prodotti (sia hardware che software) necessari alla gestione automatizzata del sistemi informativi. La realtà italiana, però, vede aziende generalmente di dimensioni poco compatibili con questa filosofia. Le nostre aziende di medie dimensioni difficilmente possono supportare i costi di una
simile infrastruttura, nata e pensata per le aziende americane medio-grandi (In USA le aziende con meno di 500 addetti sono classificate piccole ). Per questi motivi abbiamo realizzato un alternativa ad Oracle Data Guard, il prodotto PTDR che si propone di implementare lo standby database in maniera più semplice e più economica, pur non rinunciando a nessuna delle caratteristiche di sicurezza e stabilità di quel prodotto. PTDR utilizza gli stessi strumenti utilizzati da Data Guard e per questo ne mantiene esattamente la stessa affidabilità di funzionamento. Sono diverse lo modalità di esecuzione e controllo, implementate in modo che possano essere facilmente controllate e verificate anche senza l utilizzo di processi troppo sofisticati. Le maggiori differenze funzionali che PTDR introduce rispetto a Data Guard sono: 1. non è il database primario che invia le modifiche ai vari standby database ma sono i singoli standby database che leggendo il catalogo verificano se vi sono modifiche da applicare e nel caso le scaricano e le applicano, senza coinvolgere il database primario. 2. l unica attività a carico del server sul quale risiede il database primario è la copia degli archived log. 3. Occorre definire l intervallo di aggiornamento del DB secondario: stabilire ogni quanto tempo verrà effettuata la copia ed il trasferimento degli archived log. Questa scelta influenzerà la ripartenza in emergenza del sistema di recovery, infatti in caso di switch sul sistema di backup per distruzione totale del sistema primario questo intervallo di tempo rappresenta il massimo della perdita dei dati. 4. la creazione iniziale del DB secondario viene realizzata tramite copia una tantum del db primario tramite restore di un backup full, in questo modo il db primario non deve essere fermato neppure per la creazione iniziale del sistema di recovery. 5. I DB secondari, che come detto possono essere anche più di uno, sono normali DB Oracle, utilizzabili analogamente al DB primario tramite gli stessi applicativi. Le uniche limitazioni del DB secondario sono relative al fatto che non deve essere consentito modificarne i contenuti, per salvaguardare la sua identicità con il primario. Per questo sarà utilizzabile solo in modalità read-only Vantaggi dello standby database realizzato tramite PTDR 1. La procedura realizza, come risultato collaterale, la verifica puntuale che i backup siano correttamente eseguiti ed effettivamente ripristinabili, questo fornisce la tranquillità che i backup siano fatti bene, i supporti leggibili e che siano adeguati al ripristino di un database 2. il database di standby può essere aperto in modalità read only, ad esempio per scopi di data warehouse e query estemporanee, generalmente molto fastidiose su un DB transazionale.
3. il database di standby può essere promosso a database primario ed essere cosi aperto in modalità read write, per sostituire il database primario in caso di perdita oppure semplicemente per alternarlo al primario al fine di avere la certezza del corretto funzionamento del sito di recovery. 4. Il Db standby può essere usato come database di test o prototipo, però in questo caso si dovrà procedere ad una duplicazione in quanto una volta promosso a primario (e quindi modificato) non potrà più tornare ad essere la copia di standby. 5. Il database primario e quelli secondari cono completamente disaccoppiati, i malfunzionamenti di uno non hanno nessun effetto sugli altri. Le attività di trasferimento degli aggiornamenti e loro applicazione sono scollegate dal database e quindi eseguibili indipendentemente da eventuali anomalie del DB. 6. La nostra soluzione, al contrario di Data Guard, non richiede Oracle Enterprise Edition (EE), è sufficiente la Standard Edition (SE) o la Standard Edition one (SEone). Il vantaggio economico è molto interessante.