Oracle Data Guard

Oracle Data Guard e' la configurazione dell'RDBMS Oracle che consente di implementare soluzioni di disaster recovery.
In questo documento ne vengono descritti i principali concetti ed indicazioni pratiche per la configurazione ed il tuning.

Data Guard prevede la presenza di un'istanza di lavoro (detta Primary) ed una o piu' istanze dormienti (dette Standby) che vengono continuamente aggiornate e mantenute allineate rispetto all'istanza Primary per poterne prendere il posto in caso di fail.
La figura seguente riporta una semplice configurazione:

La linea fissa indica la normale modalita' di lavoro di Oracle in cui il processo Database Writer scrive sui datafile (che contengono le tabelle e gli indici della base dati) ed il processo Log Writer riporta su log i blocchi modificati. Quando e' attivo il log archiving il processo Archiver si occupa di salvare i Redo Log su una directory contenente gli Archived Redo Log.
La modalita' di log archiving consente di effettuare attivita' di recovery Point in Time o di restore fino all'ultima transazione committata.
Se viene configurato Data Guard il processo di Archiving si occupa anche di trasferire, mediante i servizi NetX, gli archived Redo Log sulle istanze di Standby. Tali istanze sono aperte in modalita' di recover ed applicano quindi il contenuto dei Redo Log mantenendo sincronizzati i dati.

Le istanze possono essere ospitate sullo stesso sistema oppure essere distribuite in rete geografica (configurazione in effetti consigliata per un disaster recovery efficace). Le possibilita' di configurazione di Data Guard sono molteplici, nel seguito sono riportate le possibilita' principali.

Le istanze Oracle possono avere due ruoli mutuamente esclusivi:

Primary Database: istanza attiva utilizzata da utenti ed applicazioni. Una sola istanza puo' essere Primary
Standby Database: istanza secondaria su cui vengono ribaltate le modifiche occorse sul Primary Database. Possono essere presenti piu' istanze di Standby

Le transazioni occorse sul Primary vengono ribaltate mediante la trasmissione e l'applicazione dei Redo Log. L'applicazione dei redo puo' avvenire in due modi:

Redo Apply: i redo vengono applicati sull'istanza in standby che e' identica alla Primary. Si parla in questo caso di Physical Standby Database.
SQL Apply: i redo log vengono convertiti in SQL ed applicati sull'istanza di Standby. Si parla in questo caso di Logical Standby Database. Un logical Standby database puo' avere una configurazione fisica differente rispetto all'istanza primary e puo' essere utilizzata, tipicamente in lettura, pur mantenendosi sempre allineata al Primary Database. Tuttavia non tutti i datatype sono supportati.

La protezione offerta da Data Guard puo' essere configurata in modo da massimizzare uno dei seguenti obiettivi:

Sicurezza: il commit si conclude quando il file di redolog e' stato inviato ad almeno un'istanza di Standby. Se non vi e' alcuna istanza di Standby in grado di raccogliere le transazioni l'istanza primaria si blocca. In questo modo ogni transazione e' applicata almeno su due basi dati distinte.
Disponibilita': molto simile al caso precedente ma nel caso di blocco delle istanze di Standby, o del servizio di rete che trasferisce i redolog, le attivita' sul Primary database proseguono ugualmente. In questo modo si rende massima la disponibilita' dei dati.
Prestazioni: i redo log vengono trasferiti al momento dell'archviazione privilegiando cosi' le prestazioni. L'invio dei redolog e' asincrono. In quest'ultima modalita' in caso di perdita dell'istanza principale il recovery avverra' fino all'ultimo redo log archiviato.

Il comando utilizzato e': ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};
Nelle prime due configurazioni e' il processo di Log writer ad effettuare l'invio dei redo log all'istanza di Standby. Nell'ultima configurazione (che e' quella di default) e' generalmente l'Archiver.
La scelta della configurazione e' molto importante per l'impatto che ha sull'RPO (Recovery Point Objective). Si puo' anche effettuare la riduzione della dimensione dei redo log e l'esecuzione di switch ad intervalli di tempo definito. L'RTO (Recovery Time Objective) di un'istanza con Data Guard puo' essere tipicamente assai ridotto: l'istanza e' gia' attiva ed aggiornata, quindi in pochi minuti gli accessi possono essere abilitati.

Il passaggio da Standby a Primary e' un cambio di ruolo e puo' avvenire in due condizioni:

Switchover: a fronte di una richiesta del DBA
Failover: in caso di caduta dell'istanza Primary

In caso di failover l'istanza di Standby prende il posto dell'istanza Primary che deve essere ricostruita (a meno di non utilizzare la funzionalita' 10g R2 di fast failover).

Configurazione

La configurazione di Data Guard viene effettuata in passi sucessivi. Nella maggior parte dei casi e' sufficiente utilizzare l'Enterprise Manager (EM), ma nel seguito vedremo comunque i principali comandi poiche' di piu' immediata comprensione. I passi principali sono i seguenti:

Configurazione della Primary Instance
- Partire da una configurazione di istanza stabile e ben definita
- Utilizzare il password file e l'SPFILE
- Configurare i parametri di LOG_ARCHIVE_DEST_X ed il DB_UNIQUE_NAME
- Eventuale configurazione degli STANDBY REDO LOG
- Attivare il log archiving
- Abilitare il FORCE logging
- Effettuare lo shutdown della base dati e lanciare un backup fisico completo
- Effettuare il MOUNT dell'istanza e salvare lo STANDBY control file
- Aprire l'istanza e salvare un PFILE
Configurazione delle Physical Standby Instance
- Verifica accurata del corretto funzionamento dell'istallazione, dell'EM, dell'accesso via sqlplus in locale ed in remoto, ...
- Configurare il listener per le istanze e definire le entry client
- Ribaltare il backup ed i file di configurazione dalla Primary Instance
- Modificare il PFILE indicando i valori corretti per il nuovo server
- Ad istanza non attiva creare l'SPFILE dal PFILE aggiornato
- Effettuare il MOUNT della base dati
- Attivare il recovery
Eventuale configurazione delle Logical Standby Instance
- Interrompere l'Apply dei Redo Log
- Configurare la Primary Instance
- Convertire la Standby Instance da Physical a Logical
- Attivare la Standby Instance

Nel seguito i passi principali vengono descritti con maggior dettaglio.

Configurazione Primary Instance

Vi sono una serie di passi da eseguire per rendere gestibile con Data Guard una istanza Oracle:

     Partire da una configurazione di istanza stabile e ben definita
Creare l'istanza con valori sufficientemente ampi di:
 MAXLOGFILE
 MAXLOGFILEMEMBERS
Anche se e' possibile modificare i parametri di inzializzazione e
la struttura dei tablespace di una Primary Instance questo richiede
attivita' sulle Standby Instance. E' quindi consigliato partire da
una configurazione stabile e definitiva.

     
Utilizzare il password file e l'SPFILE
Utilizzare SPFILE per i parametri di configurazione

Creare un password file:
orapwd

     
Configurare i parametri di LOG_ARCHIVE_DEST_X ed il DB_UNIQUE_NAME
Configurare i parametri seguenti (mutatis mutandis):
DB_NAME=server1
DB_UNIQUE_NAME=server1
SERVICE_NAMES=server1
LOG_ARCHIVE_CONFIG='DG_CONFIG=(server1,server2)'
CONTROL_FILES='/arch1/server1/control1.ctl', '/arch2/server1/control2.ctl'
LOG_ARCHIVE_DEST_1=
 'LOCATION=/arch1/server1/ 
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  DB_UNIQUE_NAME=server1'
LOG_ARCHIVE_DEST_2=
 'SERVICE=server2 
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  DB_UNIQUE_NAME=server2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
FAL_SERVER=server2
FAL_CLIENT=server1
DB_FILE_NAME_CONVERT=
 '/arch1/server2/','/arch1/server1/','/arch2/server2/','/arch2/server1/'
LOG_FILE_NAME_CONVERT=
 '/arch1/server2/','/arch1/server1/','/arch2/server2/','/arch2/server1/' 
STANDBY_FILE_MANAGEMENT=AUTO

     
Attivare il log archiving
     
Abilitare il FORCE logging
Abilitare l'archiving ed utilizzare la modalita' di FORCE logging:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

ALTER DATABASE FORCE LOGGING;

     
Effettuare lo shutdown della base dati e lanciare un backup fisico completo
Effettuare un backup full dell'istanza (con RMAN o con una copia fisica).

     
Effettuare il MOUNT dell'istanza e salvare lo STANDBY control file
STARTUP MOUNT;
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/server2.ctl';

     
Aprire l'istanza e salvare un PFILE
ALTER DATABASE OPEN;
CREATE PFILE='/tmp/initserver2.ora' FROM SPFILE;

Configurazione Physical Standby Instance

Per configurare un'istanza di Standby Physical bisogna...

     Verifica accurata del corretto funzionamento dell'istallazione, dell'EM, ...
Installare il SW Oracle RDBMS (se non era gia' presente).
La versione deve essere la stessa della Primary Instance (potrebbe
differire di minor release ma e' meglio evitare!)

     
Ribaltare il backup ed i file di configurazione dalla Primary Instance
Copiare sul sistema che ospitera' l'istanza di Standby i datafile,
il control file e l'init file creati in precedenza.
E' molto consigliato mantenere identici utenti, diritti, directory, ...

     
Modificare il PFILE indicando i valori corretti per il nuovo server
Configurare i parametri seguenti (mutatis mutandis):
DB_NAME=server1
DB_UNIQUE_NAME=server2
SERVICE_NAMES=server2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(server1,server2)'
CONTROL_FILES='/arch1/server2/control1.ctl', '/arch2/server2/control2.ctl'
DB_FILE_NAME_CONVERT=
 '/arch1/server1/','/arch1/server2/','/arch2/server1/','/arch2/server2/'
LOG_FILE_NAME_CONVERT=
 '/arch1/server1/','/arch1/server2/','/arch2/server1/','/arch2/server2/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/server2/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 
DB_UNIQUE_NAME=server2'
LOG_ARCHIVE_DEST_2=
'SERVICE=server1 
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
DB_UNIQUE_NAME=server1'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
INSTANCE_NAME=server2
FAL_SERVER=server1
FAL_CLIENT=server2

La stringa 'SERVICE=server1  indica il server remoto cui vanno
inviati i redolog e puo' avere parametri come LOGWR ASYNC...
Creare un password file utilizzando la stessa password di SYS
(su win/XX: oradim -NEW -SID server2 -INTPWD password -STARTMODE manual):
orapwd

Creare le evenutuali directory mancanti sul server di destinazione (eg. bdump, ...)

     
Configurare il listener per le istanze e definire le entry client
Basta configurare i "soliti" tnsnames.ora e listener.ora

     
Ad istanza non attiva creare l'SPFILE dal PFILE aggiornato
Creare l'SPFILE dal PFILE aggiornato
CREATE SPFILE FROM PFILE='/tmp/initserver2.ora';

     
Effettuare il MOUNT della base dati
STARTUP MOUNT;

     
Attivare il recovery
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Per verificare la trasmissione dei RedoLog puo' essere forzato uno switch con:
ALTER SYSTEM SWITCH LOGFILE;

Per controllare i redolog e' possibile utilizzare la query:
SELECT * FROM V$ARCHIVED_LOG;

Configurazione Logical Standby Instance

Per configurare un'istanza di Standby Logical bisogna innanzi tutto crearla come Physical. Quindi se non l'avete fatto rileggetevi il capitolo precedente!
Vi sono requisiti particolari per creare un'istanza Standby Logical: non sono supportati tutti i datatype ed ogni tabella deve avere una primary key. E' quindi necessario verificare la presenza di tali requisiti prima di passare dalla modalita' Physical a quella Logical. Se tutti i prerequisiti sono soddisfatti e' possibile trasformare una Physical Standby Instance in una Logical Standby Instance.

     Interrompere l'Apply dei Redo Log
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

     
Configurare la Primary Instance
Inserire un nuovo LOG_ARCHIVE_DEST

Creare il LogMiner Dictionary:
EXECUTE DBMS_LOGSTBY.BUILD;

     
Convertire la Standby Instance da Physical a Logical
ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;
Rigenerare quindi il password file e modificare i parametri della
nuova istanza.

     
Attivare la Standby Instance
ALTER DATABASE OPEN RESETLOGS;
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Un'istanza in Logical Standby ha il vantaggio di poter essere aperta ed utilizzata in lettura anche se e' meno indicata di una Physical per il disaster recovery. Poiche' le versioni successive di Oracle [NdE 11g] consentono di aprire un'istanza anche se e' Physical l'utilizzo del Logical Standby e' molto limitato.

Gestione di istanze con Data Guard

Le attivita' piu' tipiche sono:

Startup e shutdown di una Physical Standby Instance
Aprire temporaneamente un'istanza di Standby in readonly
Effettuare uno switchover
Effettuare un failover

 Startup e shutdown di una Physical Standby Instance
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SHUTDOWN IMMEDIATE;

 
Aprire temporaneamente un'istanza di Standby in readonly
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN;

Lo STARTUP di un'istanza di STANDBY avviene in READONLY per default
(Oracle conosce lo stato dai control file).
Per riprendere l'applicazione dei redo log, quindi ripristinare lo stato
di Standby e mantenere aggiornato il sistema, una volta che tutte le sessioni
sono disconnesse il comando e':
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 
Effettuare uno switchover
Bisogna convertire la Primary (S1) in Standby e quindi la Standby (S2) in Primary:
S1: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [with session shutdown];
S1: SHUTDOWN IMMEDIATE;
S1: STARTUP MOUNT;
S2: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
S2: ALTER DATABASE OPEN; # oppure SHUTDOWN e STARTUP se era stata aperta in modalita' readonly
S1: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 
Effettuare un failover
I comandi da dare sull'istanza di Standby sono:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;
In questo caso la Primary non e' piu' disponibile (e sara' da
ricostruire come Standby Instance, eventualmente utilizzando i FSF).

I comandi indicati sono corretti ma non tengono conto di tutte le possibili configurazioni (eg. errori/fault, trasferimento manuale dei redo log, Logical Standby, RAC2RAC, RAC2SingleInstance, Flashback, ...). In caso di necessita' e' opportuno fare riferimento alla manualistica Oracle.

Versioni

La funzionalita' Data Guard e' disponibile solo nella edizione Enterprise (con i relativi costi). Non richiede Option, quindi e' sufficiente una licenza database, a meno che non sia richiesto l'accesso in lettura (Active Data Guard Option).

La stabilita' in una configurazione Data Guard e' fondamentale. La versione di Oracle va quindi scelta con attenzione e, anche se generalmente e' possibile utilizzare le rolling upgrade, va mantenuta ed aggiornata con cautela.

In origine venivano trasmessi gli archived Redolog file al sito di standby e quindi applicati. La perdita massima di transazioni quindi era di un redolog file. La versione 9i ha introdotto gli Standby Redolog che consentono la trasmissione immediata delle transazioni. L'RPO e' quindi passato a poche transazioni.
Con la versione 10g e' stato introdotto il processo LNS che raccoglie i dati dal logwriter e li trasmette allo standby consentendo configuraziooni no-data-loss in Dataguard.
Le funzionalita' introdotte dalla 10g R2 sono notevoli. In particolare il fast-start failover ed i miglioramenti sull'EM... E' quindi consigliato utilizzare una 10g R2 o successiva.

Data Guard e' disponibile da molti anni su diverse versioni Oracle ed il suo utilizzo e' ben consolidato ed affidabile. Non si tratta quindi di una scelta tecnologicamente rischiosa: Oracle Data Guard puo' essere tranquillamente utilizzato su ambienti di produzione che richiedono un'elevata sicurezza dati.

Con la versione Oracle 11g (sia R1 che R2) sono molte le nuove funzionalita' introdotte in Data Guard. Tra le tante funzionalita' aggiuntive: la gestione con Enterprise Manager e' piu' completa ed efficace, e' stato introdotto un comando RMAN per duplicare direttamente per uno STANDBY DATABASE, sono possibili backup full ed incrementali sull'istanza secondaria, e' stato introdotto l'Active Data Guard che consente di accedere in lettura al DB secondario mentre i redo log vengono aggiornati, il DG Broker che offre un interfaccia semplificata (command line con dgmgrl o da EM), ...

Real-time cascade, Far Sync, Fast Sync, switchover semplificato per il RAC ed il privilegio SYSDG sono alcune delle novita' introdotte su Data Guard dalla 12c.

Con la versione 19c e' stata introdotta la funzionalita' Active Data Guard DML Redirect che consente, ai client che si collegano all'Active Standby di eseguire istruizioni DML che vengono redirette al Primary. In questo modo e' possibile ospitare, senza modifiche, applicazioni di reportistica che abbiano necessita' di eseguire alcune operazioni in scrittura sul DB.

Testo: Oracle Data Guard
Data: 25 Dicembre 2005
Versione: 1.0.5 - 25 Dicembre 2019
Autore: mail@meo.bogliolo.name