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:

Architettura Data Guard

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:

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: La protezione offerta da Data Guard puo' essere configurata in modo da massimizzare uno dei seguenti obiettivi: 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:

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:

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 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 stabilita' in una configurazione Data Guard e' fondamentale. La versione di Oracle va quindi scelta con attenzione e, anche se e' possibile utilizzare le rolling upgrade, va mantenuta ed aggiornata con cautela.

    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.

    La funzionalita' Data Guard e' disponibile solo nella edizione Enterprise (con i relativi costi).

    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 (su command line con dgmgrl o da EM), ...


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