Roberto Scarpitti
ORACLE DATA GUARD 11G OVERVIEW
Oracle Database e la business continuity: Oracle
Data Guard 11g
Pagina 1 di 11
Roberto Scarpitti
Indice
INDICE ....................................................................................................................................................................................... 2
INTRODUZIONE ........................................................................................................................................................................... 3
Benefici.............................................................................................................................................................................. 3
CONFIGURAZIONE ....................................................................................................................................................................... 4
Prerequisiti ....................................................................................................................................................................... 4
Primary Database .......................................................................................................................................................... 4
Standby Database ......................................................................................................................................................... 4
Tipologia di Standby Database ......................................................................................................................................................... 5
METODI DI PROTEZIONE .............................................................................................................................................................. 6
Esempio di configurazione: physical standby database ................................................................................................................ 7
SERVIZI OPERATIVI DELLA TECNOLOGIA DATA GUARD .................................................................................................................... 8
Redo Transport Services ............................................................................................................................................ 8
Apply Services ................................................................................................................................................................ 8
Role Transitions ............................................................................................................................................................. 8
DATA GUARD BROKER................................................................................................................................................................. 9
DATA GUARD E LE TECNOLOGIE AVANZATE DI ORACLE ................................................................................................................. 10
Oracle Real Application Clusters (RAC) .............................................................................................................. 10
Flashback Database.................................................................................................................................................... 10
Recovery Manager (RMAN)...................................................................................................................................... 10
PERCHÉ SCEGLIERE ORACLE DATA GUARD 11G ........................................................................................................................... 11
Pagina 2 di 11
Roberto Scarpitti
Introduzione
Oracle Data Guard 11g è l’evoluzione naturale di Oracle Standby Database di
Oracle 8i, passando dalle versioni 9i e 10g.
Per quanto riguarda la sola base dati, la tecnologia Oracle Data Guard può essere
impiegato in ambito high availability, data protection, disaster recovery e business
continuity basandosi semplicemente sul motore Oracle 11g e sulle potenzialità
offerte dalla versione Enterprise Edition, senza dover installare nessun altro
software aggiuntivo o apparato hardware.
Data Guard fornisce inoltre servizi adeguati a creare, mantenere e monitorare uno
o più standby databases, prevenedo le situazione di disastro o semplicemente di
corruzione di dati, consentendo di mantenere costantemente allineati due o più
database identici, ubicati in siti differenti, anche a distanze rilevanti, purché
connessi via network tra loro. Questo permette di attivare l’istanza secondaria in
qualsiasi istante, nel momento in cui la primaria divenisse inutilizzabile per cause
volute o meno, schedulate o no, riducendo al minimo il tempo di downtime e
soprattutto prevenendo la perdita di dati.
Data Guard può inoltre integrare in maniera del tutto nativa, le potenzialità di
Oracle Real Application Cluster, realizzando in maniera sinergica la tecnologia Real
Application Guard che garantisce una protezione completa a fronte di guasti
hardware, software e di disastri.
Grazie allo standby database è possible demandare all’istanza secondaria sia le
procedure di backup che la reportistica massiva ed invasiva, normalmente attuata
sulle istanze di produzione direttamente, semplicemente integrandosi con l’utility
Recovery Manager di Oracle.
Benefici
Come meglio illustrato in seguito sono molteplici le motivazioni che inducono a
scegliere la tecnologia Data Guard. Eccone un elenco:

Non si hanno perdite di dati in caso di disastro ed è inoltre possibile
garantire un sistema in alta affidabilità.

E’ possibile scegliere le politiche di protezione dei dati e di ripristino a
fronte di un disastro, in base alle esigenze applicative.

La gestione della struttura Data Guard nel suo complesso può essere fatta
o da riga comando o tramite interfacce http(Oracle Enterprise Manager).

Attivazione del sito di DR a ruolo primario, per attività di manutenzione
programmata al termine della quale il sito primario ritorna ad assumere il
suo ruolo nativo.

Distribuzione dei carichi di lavoro su tutti i nodi della configurazione, con
differenziazione dei ruoli assunti dai database(OLTP, DDS, DATA
WAREHOUSE).

Integrazione di Data Guard con altre opzioni ed utility offerte da Oracle
(RAC ed RMAN) per garantire massima protezione, massima disponibilità e
massime performance.
Pagina 3 di 11
Roberto Scarpitti
Configurazione
Oracle Data Guard si basa essenzialmente sulla presenza di due database identici,
allineati applicando in modalità sincrona o a asincrona gli archivelogs generati dal
prim Oracle Data Guard si basa essenzialmente sulla presenza di due database
identici, allineati applicando in modalità sincrona o a asincrona gli archivelogs
generati dal primario. Di seguito la topologia appena descritta:
Prerequisiti
L’installazione base in modalità primario-secondario di Oracle Data Guard prevede
essenzialmente che vengano rispettati i seguenti prerequisiti:
1. RDBMS Oracle 11g Database Enterprise Edition comprendente la feature
Data Guard e apertura della base dati in modalità ARCHIVELOG.
2. Due server che abbiano la stessa configurazione software ed hardware ma
per cui è possibile decidere di utilizzare hardware ridimensionato sui sito
secondario, riducendo così i costi complessivi di infrastruttura. E’ preferibile
che i due server siano ubicati in postazioni fisicamente separate, questo
per garantire, in caso di disaster, che almeno uno dei due non venga
compromesso.
3. Un apparato di rete efficiente che consenta il trasporto degli archive logs
dal server primaio verso i clone in tempi brevi e senza perdita di dati.
Per quanto riguarda la configurazione base, non è necessario alcun apparato disco
esterno o condiviso, il sistema lavora tranquillamente sui dischi interni. In
configurazione RAC invece, essendo Cluster, al contrario è necessario far uso di
dischi shared.
La gestione dei siti primario e secondari può essere fatta utilizzando riga comando
e SQL*PLUS oppure utilizzando l’interfaccia fornita da Data Guard Broker Interface
la cui utility di sistema è DGMGRL oppure direttamente integrata in Oracle
Enterprise Manager.
Primary Database
La tecnologia Data Guard prevede la presenza di un database primario di
produzione attivo in modalità primary role, in single instance od in RAC, il quale
allinea il database secondario attraverso l’invio e l’applicazione degli archivelogs.
Il database primario deve quindi essere sempre aperto in modalità lettura/scrittura
ovviamente.
Standby Database
Lo standby database è ottenuto come restore da una copia di backup a freddo del
database primario, per cui consistente. E’ possibile attivare fino a trenta copie di
standby database tutte appartenenti ad un’unica configurazione Oracle Data
Guard.
Opportunamente configurato sia lato primary che standby, il meccanismo di
trasmissione dei redologs ed applicazione degli stessi nei siti remoti è
completamente automatico.
Come il sito primario, anche lo standby
configurazione single-instance o RAC.
database
può
appartenere
alla
Pagina 4 di 11
Roberto Scarpitti
Lo standby database a differenza del primario è generalmente aperto in modalità
recover, ovvero non accessibile all’esterno, ma in continuo aggiornamento. In
questo modo tutte le transazioni generate dal sito primario ed inviate tramite i
processi Oracle al sito secondario, vengono applicate sullo standby.
Ovviamente le politiche di recover e la scelta della configurazione complessiva
dipendono fortemente dalle esigenze applicative.
Dalla versione Oracle 9i il database secondario può essere aperto e accessibile e
dalla 11g è addirittura possibile lavorare in configurazione updatable snapshot
sul secondario, come meglio spiegato di seguito, per cui con istanza aperta in
modalità read/write.
Tipologia di Standby Database
Per procedere con il disegno dell’architettura in Standby è necessario decidere a
priori due aspetti: che tipo di database secondario creare e quale livello di
protezione attuare all’intera architettura logica.
Physical standby database
Riprende la configurazione originaria del classico Standby Database: il database
secondario è identico a quello primario, blocco per blocco; la sincronizzazione
avviene attraverso l’applicazione degli archive logs e la base dati è chiusa, non
accessibile dall’esterno in quanto in stato di recover. Dalla versione 11g release
1 (11.1.X) i redo log sullo standby database possono essere applicati anche se
il database è aperto in modalità read-only. Questa potenzialità garantisce la
massima protezione dei dati ma anche la possibilità di accedere in lettura per
reportistica agli stessi dati di produzione, ma lavorando su database remoto.
Logical standby database
La base dati primaria è identica allo standby solo a livello di dati mentre
l’organizzazione fisica e la struttura dati potrebbe essere differente;
L’allineamento tra le basi dati avviene attraverso l’applicazione diretta degli
statement SQL estratti dai redo del primario ed applicati direttamente allo
standby database, per cui la base dati secondaria dovrà essere aperta. Questo
consente l’utilizzo del database secondario non solo per garantire il disaster
recovery, bensì anche per sfruttare meglio le attività di reportistica ed infine
per poter aggiornare l’RDBMS Oracle software con il minimo downtime di
sistema sul primario.
Snapshot Standby Database
In questo caso lo standby è aperto e completamente aggiornabile! Le
transazioni generate dal primario non sono applicate direttamente sul
secondario finché quest’ultimo non viene riportato nella modalità di physical
standby database, effettuando un rollback su tutte le transazioni localmente
applicate sullo snapshot standby database. In sintesi il physical standby può
essere aperto in modalità snapshot ed adoperato come se fosse un database
primario, accedendo ai dati in lettura/scrittura per fare test o reporting massivi
su delle immagini di database primario ed al termine di tutto, riattivare
l’allineamento delle base dati tra primario e secondario.
Ovviamente finché su tutte le transazioni applicate sullo snapshot standby
database non viene effettuata la rollback, questo non sarà disponibile per il sito
di DR e la tempistica necessaria ad un eventuale failover o switchover è
direttamente legata alla quantità di transazioni applicate.
Pagina 5 di 11
Roberto Scarpitti
Metodi di protezione
La scelta del metodo di protezione dati dipende dalle politiche adottabili a fronte
del disastro, ma anche dalle performance che si vorrebbero mantenere sul sito
primario.
Sulla base di queste scelte vengono configurate le tecnologie per determinare il
livello di sincronizzazione tra le basi dati ma anche quale livello di rischio di perdita
dati garantire. Data Guard consente di scegliere di massimizzare uno dei tre
ambiti: protezione dati, disponibilità di servizio e performance:
1. Maximum protection: garantisce il massimo livello di disponibilità e
protezione dei dati sul database primario e secondario, assicurando una perdita
dati in caso di disaster pari a zero. In questo caso i redologs del primario sono
immediatamente inviati dal primario verso il secondario, realizzando così una
sincronizzazione delle basi di dati completa: la transazione sul primario è
completata e committata solo quando c’è la certezza che questa sia disponibile
ed applicata sul server secondario. Tale soluzione è adottata per sistemi ad alta
protezione con almeno due standby database ed un primario in cui basta che
almeno uno dei due DB secondari abbia ricevuto la transazione affinché il
primario possa ultimarla. Nel momento in cui lo standby database risulta
irraggiungibile anche il primario viene bloccato, assicurando quindi che
nessuna transazione venga persa. Tale soluzione è possibile solo per physical
standby database.
2. Maximum availability: questa configurazione garantisce la massima
protezione a fronte di failures dovute ai componenti singoli della base
dati(corruzione fisica dei datafiles) senza compromettere la disponibilità del
sistema primario. Anche in questo caso, la transazione sul primario è
completata solo quando c’è la certezza che questa sia disponibile su almeno un
server secondario però, a differenza della modalità Maximum Protection, nel
momento in cui lo standby database non è più disponibile(a causa di problemi
di rete per esempio), il primario continua a lavorare non creando quindi alcun
disservizio. In questo modo lo standby database può temporaneamente
divergere dal primario ma, nel momento in cui lo standby torna ad essere
disponibile, verrà automaticamente sincronizzato al primario senza perdita di
dati. Tale configurazione è disponibile sia per il physical che per il logical
standby database.
3. Maximum performance: è la configurazione di default in cui viene garantito
il massimo livello di performance ma anche una limitata probabilità di perdita
di dati in quanto le transazioni vengono spedite dal primario al secondario in
modalità asincrona dai processi Oracle LGWR o ARCH. La commit sulle
transazioni del primario non è minimamente condizionata dalla corretta
applicazione della transazione sul secondario. Se lo standby database si rende
non disponibile per qualunque ragione, il database primario continua a lavorare
indisturbato, evitando perdite di performance e di servizio.
Per tutte e tre le possibili configurazioni di Data Guard è necessario apporre
modifiche opportune ai parametri di istanza primaria e secondaria
dell’infrastruttura, per cui sarà necessario un fermo del database primario, un
backup consistente dello stesso, un restore sul secondario ed un avvio dell’istanza
in modalità recover.
La seguente tabella riassume le caratteristiche salienti delle tre modalità:
Protection Mode
Maximum Protection
Maximum Availability
Maximum Performance
Rischio di perdita di dati
Nullo; protezione doppia dalle
failures
Nullo; protezione singola dalle
faillures
Modalità di invio transazioni
Limitato tra 0 e diversi secondi
Asincrono attraverso LGWR o ARCH
Sincrono verso due siti tramite LGWR
Sincrono attraverso LGWR
La configurazione maggiormente utilizzata è quella di default ovvero Maximum
Performance, in cui è più importante mantenere alto il livello di servizio sul master
Pagina 6 di 11
Roberto Scarpitti
mentre sul secondario, è consentito un margine di possibilità di perdita di dati e
quindi di divergenza dal primario.
La modalità di aggiornamento del secondario può variare a seconda delle esigenze,
ma soprattutto della frequenza con cui vengono generati gli archive logs sul
primario, per cui si può scegliere di archiviare in automatico le transazioni sul
secondario ogni volta che viene emesso un archive log nuovo, piuttosto che
demandare a degli shell script tali compiti.
Esempio di configurazione: physical standby database
Di seguito ho rappresentato graficamente la configurazione Data Guard su due siti, Master e Secondario, su una
architettura a tre livelli basata su SAP. La prima rappresentazione riguarda il caso di funzionamento normale, la seconda
invece il caso di disastro.
CONFIGURAZIONE IN MODALITA’ NORMALE
Client level SAP Gui
Network
Application Level
(SAP Server)
Oracle Net
Data Base Level Master Site
(Primary Database – Active Instance)
Data Base Level Remote Site
(Secondary Database – Recover Instance)
Network
base dati
archive log
base dati
archive log
Come si può notare dal grafico la base dati è acceduta solo dall’application server il quale punta al Master Site, mentre il
database server secondario non viene acceduto. Sarà il database primario ad inviare le transazioni generate dal primario
anche sul secondario tramite gli archive logs e, quindi ad applicarle sul secondario mantenendo allineati i database. In caso
di Disaster la nuova configurazione diventerà la seguente, per quanto concerne la base dati:
Client level SAP Gui
CONFIGURAZIONE IN MODALITA’ DISASTER
Network
Application Level
(SAP Server)
Oracle Net
Data Base Level: disastered site
(Primary Database – defunct instance)
base dati
log
archive
Data Base Level Remote Site
(Primary Database – Active Instance)
base dati
archive log
Dopo il disastro il database primario è inaccessibile, lo standby è diventato primario e l’applicazione punterà al sito remoto
invece che a quello originario senza aver perso nessuna transazione derivante dal primario.
Pagina 7 di 11
Roberto Scarpitti
Servizi operativi della tecnologia Data Guard
La tecnologia Data Guard fa uso di tre tipi di servizi: uno dedicato alla trasmissione
dei redolog, uno all’applicazione degli stessi ed uno alla gestione dei ruoli delle
istanze.
Redo Transport Services
Sono adibiti al trasferimento automatico del contenuto dei redolog da database
primario agli standby database. Queste le attività svolte:
o
Trasmissione dei redolog dal database primario a tutti gli standby
presenti in configurazione Data Guard
o
Risoluzione del gap esistente tra gli archive log spediti dal primario e
quelli effettivamente pervenuti sui secondary; la differenza può essere
causata da una caduta di rete o temporanea assenza dei database
secondari
o
Individuazione degli archive log persi o corrotti sugli standby database
e sostituzione degli stessi, richiedendoli al primario o ad altri database
secondary che li hanno ancora disponibili
Apply Services
Si occupano di applicare le transazioni provenienti dal database primario, sullo
standby, garantendone l’allineamento. La sincronia è gestita o tramite
l’applicazione degli archivelog o, ove opportunamente configurato, direttamente
degli standby redolog del secondario. La principale differenza tra il physical ed il
logical standby database risiede nella modalità in cui i redolog sono applicati:
o
Nel physical standby database Data Guard utilizza la tecnologia REDO
APPLY applicando le transazioni sul database secondario in modalità
tradizionale con DB in stato recover e non accessibile.
o
Nel logical standby database Data Guard utilizza la tecnologia SQL
APPLY trasformando le transazioni pervenute dal database primario in
statement sql applicate al database secondario aperto, in stato readwrite.
Role Transitions
Un database Oracle può essere attivato in modalità primaria o standby: questi
sono i ruoli associati alle istanze. Con Oracle Data Guard è possibile scambiare
il ruolo delle istanze tramite le operazioni di switchover e failover.
o
Switchover è il ruolo che consente di eleggere uno dei physical
standby database a primario e, successivamente a far assumenre al
primario originario il suo ruolo, senza perdita di dati. Questa tecnica
viene impiegata normalmente durante attività di manutenzione
programmata sul database primario, per cui il database primario
assume il ruolo di standby ed uno dei secondari assumono quello di
primario fino al termine della manutenzione. Finita l’attività I ruoli
vengono nuovamente scambiati con un downtime molto basso e senza
perdita di transazioni, il ruolo è quindi reversibile.
o
Failover invece è la situazione in cui il primario risulta inaccessibile
per cui lo standby database assume il ruolo di primario senza perdita di
dati ed in modalità irreversibile, per cui senza la possibilità di ritornare
a ruolo secondario.
Lo scambio di ruoli all’interno della configurazione in Data Guard è gestita
tramite comandi SQL oppure tramite Data Guard Broker di OEM o tramite
l’utility di riga comando DMGRL.
Pagina 8 di 11
Roberto Scarpitti
Data Guard Broker
Data Guard broker è un framework di gestione distribuita utilizzato per la
creazione, la gestione e la manutenzione di Data Guard. Si può utilizzare sia
Oracle Enterprise Manager graphical user interface (GUI) sia Data Guard
command-line interface (DGMGRL).
Le principali operazioni consentite tramite questo tool sono:
o
Configurazione di Oracle Data Guard, inclusi la definizione del redo
transport services e degli apply services.
o
Gestione e monitoring dell’intero sistema Data Guard da un unico
sistema in configurazione single instance o RAC.
o
Switchover ed failover da interfaccia grafica o da riga comando tramite
l’utility DGMGRL.
o
Abilitazione della facility fast-start failover con cui, in maniera del tutto
automatica viene avviato il failover verso un’istananza di standby
specificata, nel momento in cui Data Guard Broker si accorge che
l’istanza primaria è diventata inaccessibile, senza l’intervento di un
DBA.
Tramite Oracle Enterprise Manager è inoltre possibile:
o
Creare un physical o logical standby database partendo da una copia di
backup consistente di un database primario.
o
Aggiungere un nuovo standby database ad una configurazione Data
Guard già presente.
o
Monitorare l’intero sistema, verificando la frequenza di applicazione dei
redologs, le informazioni relative a problematiche di disallineamento e
performance.
o
Avviare o chiudere istanze.
o
Verificare eventi e schedulare jobs.
o
Avviare processi di backup e recovery.
Pagina 9 di 11
Roberto Scarpitti
Data Guard e le tecnologie avanzate di Oracle
Per massimizzare i servizi in alta affidabilità rendendo i sistemi ancora più sicuri
e facilmente ripristinabili a fronte di failure, Oracle integra in maniera del tutto
nativa Data Guard con RAC, Flash Back Recovery e Recovery Manager.
Oracle Real Application Clusters (RAC)
Il connubio tra RAC e Data Guard porta ad avere i sistemi al più alto livello di
protezione ed affidabilità, garantendo continuità di servizio a fronte di problemi
hardware, software, corruzione dati e perdita di dati.
Flashback Database
Flashback Database consente invece di recuperare i dati a fronte di corruzione
logica degli stessi o a fronte di errori umani, andando a ripristinare le
informazioni ad un istante prima dell’avvenuta corruzione o perdita di dati,
eliminando la necessità di restorare l’intero database da un backup consistente.
L’utilizzo del Flashback Database consente inoltre di ridurre il tempo di delay di
applicazione dei redologs sullo standby database, normalmente attuato per
proteggere contro errori logici o di corruzione. Riducendo il tempo di delay si
riduce anche il tempo di failover e di switchover.
Infine attivando Flashback Database sullo standby database si evita di dover
ricreare completamente i siti secondari dopo il failover.
Recovery Manager (RMAN)
Recover Manager(RMAN) è una feature integrata in tutte le installazioni Oracle
che non necessita particolari configurazioni ma che, integrato con Data Guard,
consente di creare un nuovo standby database dal backup del primario
utilizzando il comando DUPLICATE, attivando le politiche di backup sullo
standby database invece che sul primario.
Pagina 10 di 11
Roberto Scarpitti
Perché scegliere Oracle Data Guard 11g
I principali benefici offerti da questa architettura sono principalmente 6:
1. Implementazione dell’alta affidabilità e protezione da eventi di disastro,
grazie alla configurazione distribuita, ma anche di protezione a fronte di
corruzione fisica dei dati, con bassi tempi di disservizio, garantendo zero
data loss.
2. Differenziazione nella scelta delle politiche di implementazione di Data
Guarding rispetto agli aspetti salienti quali performance, protezione dei dati
e livello di servizio.
3. Centralizzazione e semplificazione del processo di gestione di Data Guard,
con l’introduzione di Data Guard Manager, una interfaccia grafica di Oracle
11g.
4. Assunzione dei ruoli di Switchover per lo switch temporaneo del sito
primario sullo standby, a fronte di manutenzione preventiva(reversibile) o
del suolo di Failover in caso di disastro o failure(irreversibile).
5. Ottimizzazione delle risorse hardware utilizzate, riducendo il carico di
lavoro sul server primario e distribuendolo invece sui siti di standby.
6. Integrazione di Data Guard con RAC ed RMAN che consente di garantire
massima protezione, massima disponibilità e massime performance.
Pagina 11 di 11