RAC, Data Guard e Stream sono tre strumenti nel sistema di alta disponibilità di Oracle. Ogni strumento può essere utilizzato indipendentemente o in combinazione. Hanno focus diversi ed sono applicabili in contesti differenti.
RAC eccelle nel gestire i singoli punti di fallimento e il bilanciamento del carico. Pertanto, RAC viene comunemente utilizzato nei sistemi critici 24/7. Tuttavia, nella soluzione RAC, i dati esistono in una sola copia. Sebbene sia possibile evitare guasti dei dispositivi di archiviazione attraverso meccanismi come RAID, i dati stessi non hanno ridondanza, il che li rende suscettibili a singoli punti di fallimento.
Data Guard fornisce protezione dei dati attraverso l'uso di dati ridondanti. Utilizzando meccanismi di sincronizzazione dei log, Data Guard garantisce la sincronizzazione tra i dati ridondanti e i dati principali. Questa sincronizzazione può essere realizzata in vari modi, come in tempo reale, ritardata, sincrona o asincrona. Data Guard viene comunemente utilizzata per soluzioni di ripristino da disastri remoti e alta disponibilità per piccole imprese. Sebbene consenta query di sola lettura sulla macchina di standby per alleviare la pressione sulle prestazioni del database principale, Data Guard non è principalmente concepita come una soluzione per le prestazioni.
Gli stream, basati su Oracle Advanced Queue, consentono la sincronizzazione dei dati e offrono configurazioni flessibili a diversi livelli. Poiché Oracle fornisce un ampio supporto allo sviluppo, incluso un ricco set di API, gli stream sono più adatti per il condivisione dei dati a livello di applicazione.
Cos'è Data Guard?
In un ambiente Data Guard, ci sono almeno due database: uno in stato aperto che fornisce servizi esterni, noto come Database Primario, e l'altro in stato di recupero, noto come il Database di Riserva. Durante l'esecuzione, il Database Primario serve i client e le operazioni utente vengono registrate nei log online e archiviati, che vengono successivamente trasmessi al Database di Riserva attraverso la rete. Questi log vengono riprodotti sul Database di Riserva per raggiungere la sincronizzazione dei dati tra i due.
Oracle Data Guard ottimizza ulteriormente questo processo, automatizzando e semplificando i compiti di trasmissione dei log e di ripristino, fornendo allo stesso tempo una vasta gamma di parametri e comandi per semplificare il lavoro degli amministratori di database (DBA).
Se ci sono fattori previsti che richiedono l'arresto del Database Principale, come ad esempio aggiornamenti del software o hardware, il Database di Riserva può essere commutato per diventare il Database Principale e continuare a fornire servizio ai client. Questo minimizza il tempo di inattività del servizio e garantisce l'integrità dei dati. In caso di problemi imprevisti che rendono il Database Principale non disponibile, il Database di Riserva può essere forzatamente commutato per diventare il Database Principale e continuare a fornire servizio ai client. Il livello di perdita di dati in tali casi dipende dal livello di protezione dei dati configurato. Pertanto, i database Principale e di Riserva sono ruoli concettuali che non sono fissi a database specifici.
Architettura Data Guard
L'architettura Data Guard può essere divisa in tre parti funzionali:
1) Redo Send:
Durante l'esecuzione del Database Principale, i log redo vengono generati costantemente e devono essere inviati al Database di Riserva. Questa azione di invio può essere eseguita dai processi LGWR o ARCH del Database Principale. Destinazioni diverse per l'archiviazione possono utilizzare metodi diversi, ma per una destinazione specifica, può essere selezionato solo un metodo. La scelta del processo ha un impatto significativo sulle capacità di protezione dei dati e sulla disponibilità del sistema.
2) Ricezione Redo:
Il processo RFS (Remote File Server) nel Database di Riserva riceve i log e li scrive sia nei file del Standby Redo Log che nei file del Archived Log, a seconda del metodo di trasporto dei log del Database Principale e della posizione del Database di Riserva. Se i log vengono scritti nei file del Standby Redo Log, allora quando si verifica uno switch di log sul Database Principale, questo attiva uno switch di log sul Standby Redo Log del Database di Riserva e archivia quel Standby Redo Log. Se i log vengono scritti nei log archiviati, questa azione può essere considerata come un'operazione di archiviazione in sé.
3) Redo Apply:
Il servizio redo apply è responsabile della riproduzione dei log del database principale sul database di standby, realizzando così la sincronizzazione dei dati tra i due database.
Dipende da come il database di backup riapplica i log, esistono due tipi: Physical Standby e Logical Standby.
Basandosi sul momento in cui avviene l'applicazione di Redo, esistono anche due tipi:
a) Applicazione in Tempo Reale: Questo metodo richiede l'uso del Standby Redo Log. Ogni volta che un log viene scritto nel Standby Redo Log, attiva il recupero. Il vantaggio di questo metodo è che riduce il tempo necessario per il failover del database poiché i log rimanenti sono già recuperati in tempo reale.
b) Applica a Archivio: Questo metodo applica i log quando si verifica lo switch dei log nel Database Primario e attiva l'archiviazione nel Database di Standby. Il recupero viene avviato dopo il completamento del processo di archiviazione. Questa è anche la modalità di recupero predefinita.
Database di Riserva Fisica vs. Database di Riserva Logica
Esistono due tipi di Database di Riserva: Database di Riserva Fisica e Database di Riserva Logica.
1. Database di Riserva Fisica:
Un database di riserva fisica è identico a un database Primario. Data Guard mantiene il database di riserva fisica attraverso l'applicazione di REDO. Generalmente, quando il database di riserva fisica non sta applicando REDO, può essere aperto in modalità READ ONLY. Se nell'area del database è specificata una Flashback Area, può persino essere temporaneamente impostato in modalità READ WRITE per eseguire determinate operazioni. Dopo aver completato le operazioni necessarie, il database può essere ripristinato allo stato precedente alla modalità READ WRITE utilizzando la funzionalità Flashback Database, consentendo così la continuazione dell'applicazione dei dati REDO dal database Primario.
Nota: La funzionalità di Physical Standby è stata migliorata in Oracle 11g. In questa versione, Physical Standby può continuare ad applicare i dati REDO mentre si trova in modalità OPEN READ ONLY. Ciò migliora notevolmente l'usabilità dei database Physical Standby.
Caratteristiche del Physical Standby:
1) Recupero da disastri e alta disponibilità: Physical Standby fornisce una soluzione robusta ed efficiente per il recupero da disastri e l'alta disponibilità. Semplifica la gestione dello switchover/failover e riduce il downtime pianificato o non pianificato.
2) Protezione dei dati: Con un database Physical Standby, Data Guard garantisce che la perdita di dati sia minimizzata, anche in caso di disastri imprevisti.
3) Riduzione del carico di lavoro del database principale: Spostando alcuni compiti, come i backup e le query in sola lettura, sul database di standby fisico, si possono risparmiare le risorse CPU e I/O sul database principale.
4) Migliorata prestazione: Il meccanismo di applicazione REDO utilizzato nei database Physical Standby opera a livello più basso del processo di recupero, ignorando l'esecuzione del codice SQL. Ciò comporta l'efficienza e la prestazione massime.
2. Standby Logico:
Un database Standby Logico viene creato in base al database Primario (o ai suoi backup o repliche, come ad esempio il Standby Fisico). Quindi, all'inizio, è simile a un database Standby Fisico. Tuttavia, poiché un Standby Logico applica i dati REDO tramite l'esecuzione di SQL, la sua struttura dei file fisici e persino la struttura logica dei dati possono essere diverse rispetto al database Primario.
A differenza del Physical Standby, un Logical Standby è normalmente aperto in modalità READ WRITE, permettendo agli utenti di accedervi in qualsiasi momento. In altre parole, l'esecuzione di SQL avviene mentre il Logical Standby si trova in uno stato OPEN. Ciò comporta vantaggi e svantaggi. A causa della natura dell'esecuzione di SQL, esistono limitazioni operative su alcuni tipi di dati e alcune istruzioni DDL/DML in un Logical Standby. È possibile verificare i tipi di dati non supportati nella vista DBA_LOGSTDBY_UNSUPPORTED. Se vengono utilizzati tali tipi di dati, non è possibile garantire un completo livello di coerenza nel database.
L'apertura in modalità READ WRITE di un Logical Standby lo rende adatto per essere utilizzato come sistema di reporting, alleggerendo il carico di lavoro del sistema.
Caratteristiche del Logical Standby:
Oltre alle caratteristiche menzionate in precedenza per il Physical Standby, come ripristino di disaster recovery, alta disponibilità e protezione dei dati, il Logical Standby presenta le seguenti funzionalità:
1) Utilizzo efficiente delle risorse hardware sul server di backup: Un database Logical Standby può essere utilizzato per creare indici aggiuntivi, viste materializzate e soddisfare esigenze specifiche aziendali. È inoltre possibile creare nuovi schemi (che non esistono nel database Primario) ed eseguire operazioni DDL o DML che non sono appropriate sul database Primario.
2) Riduzione del carico di lavoro del database principale: Mantenendo aperto il database Logical Standby mentre rimane sincronizzato con il database Principale, esso può fornire sia la protezione dei dati che le operazioni di reporting. Ciò allevia il database Principale dai compiti di reporting e query, risparmiando preziose risorse di CPU e I/O.
3) Aggiornamenti fluidi: Logical Standby può essere utilizzato per operazioni come gli aggiornamenti tra versioni diverse e il patching del database.
Modalità di Protezione dei Dati
Data Guard consente tre modalità di protezione dei dati: Protezione Massima, Disponibilità Massima e Prestazioni Massime.
1. Protezione Massima:
Questa modalità garantisce la perdita totale di dati zero. Per raggiungere questo scopo, tutte le transazioni devono non solo essere scritte nei log di redo online locali prima del commit, ma anche contemporaneamente scritte nei log di redo di standby nel database di standby. I dati REDO devono essere accessibili in almeno un database di standby (se ne esistono più) prima che possano essere confermati sul database primario. In caso il database di standby diventi non disponibile a causa di un'interruzione (ad esempio, interruzione di rete), il database primario verrà spento per prevenire la perdita di dati.
Abilitare questa modalità richiede che il Database di Riserva venga configurato con i Log di Redo di Riserva e che il Database Principale utilizzi la modalità LGWR, SYNC, AFFIRM per l'archiviazione nel Database di Riserva.
2. Disponibilità Massima:
Questa modalità fornisce il livello più alto di strategia di protezione dei dati senza influire sulla disponibilità del database Principale. Segue un'implementazione simile a quella di Protezione Massima, dove le transazioni locali devono essere scritte nei Log di Redo di almeno un database Di Riserva prima del commit. Tuttavia, la differenza è che se si verifica un errore che rende il database Di Riserva inaccessibile, il database Principale passerà automaticamente alla modalità Prestazione Massima invece di arrestarsi. Una volta che il database Di Riserva si ripristina, il database Principale tornerà automaticamente alla modalità Disponibilità Massima.
Sebbene questa modalità miri a minimizzare la perdita di dati, non può garantire una coerenza dei dati assoluta. Come per la Massima Protezione, questa modalità richiede che il Database di Riserva sia configurato con i Log di Riserva e che il Database Principale utilizzi la modalità LGWR, SYNC, AFFIRM per l'archiviazione sul Database di Riserva.
3. Prestazione Massima:
Questa modalità fornisce il livello più alto di strategia di protezione dei dati senza influire sulle prestazioni del database Primario. Le transazioni possono essere confermate in qualsiasi momento e i dati REDO dal database Primario corrente devono essere scritti almeno in un database di Riserva, sebbene ciò possa essere fatto in modo asincrono. In condizioni di rete ideali, questa modalità può fornire una protezione dei dati simile a quella della Massima Disponibilità, avendo solo un leggero impatto sulle prestazioni del database Primario. Questa è la modalità di protezione predefinita quando si crea un database di Riserva. Può essere realizzata utilizzando sia i processi LGWR ASYNC che ARCH, e i log REDO di Riserva non sono richiesti per il database di Riserva.
Passaggi per modificare la modalità di protezione dei dati:
1. Arresta il database e riavvialo nello stato Mount. Se si tratta di una configurazione RAC, arresta tutte le istanze e avvia solo un'istanza nello stato Mount.
2. Modifica la modalità utilizzando la seguente sintassi:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
Ad esempio: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Apri il database: ALTER DATABASE OPEN;
4. Conferma la modalità modificata di protezione dei dati:
SQL>seleziona modalità_protezione, livello_protezione da v$database;
Servizi di Applicazione del Log
Data Guard garantisce la coerenza tra il database Primario e i database di Standby applicando il REDO. Nel dettaglio, supportando silenziosamente questo processo, ci sono i rinomati Servizi di Applicazione del Log. Esistono due tipi di Servizi di Applicazione del Log:
1. Applicazione REDO: Esclusiva per i database Standby fisici, li mantiene sincronizzati con il database Primario attraverso la recovery dei media.
2. SQL Apply: Esclusivo per i database Standby logici, la sua funzionalità principale consiste nell'analizzare le istruzioni SQL attraverso LogMiner ed eseguirle sul lato Standby.
Quindi, quando si applicano i dati REDO, il database Standby fisico deve essere in uno stato MOUNT, mentre il database Standby logico è aperto in modalità READ WRITE per l'applicazione dei dati REDO. Tuttavia, gli oggetti mantenuti sono impostati come di sola lettura predefinitivamente e non possono essere modificati direttamente nel database Standby logico.
Proteggi il database Oracle con una soluzione professionale
Oracle Data Guard è una soluzione robusta per la disponibilità elevata, la protezione dei dati e il ripristino dopo disastri. È uno strumento fondamentale per le aziende che non possono permettersi tempi di inattività significativi o perdita di dati. Tuttavia, per proteggere ulteriormente il tuo ambiente del database, si consiglia di eseguire il backup del database Oracle con una soluzione di backup e ripristino dopo disastri professionale.
Vinchin Backup & Recovery fornisce funzionalità potenti per proteggere i tuoi database sia nelle macchine virtuali che nei server fisici, ed è abbastanza automatico, flessibile ed efficiente. Fornisce la protezione multi-tipo dei database di Oracle DB, MySQL, SQL Server, Postgres Pro e MariaDB, supportando la compressione del database, la gestione centralizzata dei lavori, strategie di backup intelligenti, backup del database in caldo e un avanzato supporto per SQL Server/Oracle. Inoltre, supporta anche una funzionalità potente di protezione dai ransomware e di migrazione V2V tra più di 10 piattaforme virtuali.
Vinchin Backup & Recovery è stato selezionato da migliaia di aziende e anche tu puoi iniziare ad utilizzare questo potente sistema con un periodo di prova gratuito di 60 giorni con tutte le funzionalità! Inoltre, contattaci e lasciaci le tue esigenze, e riceverai una soluzione adatta al tuo ambiente IT.
Conclusione
Oracle Data Guard è un componente fondamentale per qualsiasi distribuzione di database Oracle a livello aziendale, offrendo una soluzione completa per il ripristino in caso di disastro, la disponibilità elevata, la protezione dei dati e il bilanciamento del carico di lavoro. La sua architettura flessibile e i vari modi di funzionamento lo rendono adattabile a un vasto spettro di esigenze aziendali e requisiti operativi.
Puoi scegliere Vinchin Backup & Recovery per backup e recupero facile dei tuoi database Oracle. Non perdere il trial gratuito!
