Questo documento riporta i dettagli della tecnica di database flashback
per effettuare il ripristino di
un sito secondario di Disaster Recovery (DR) basato su Oracle Data Guard.
Data Guard e' la soluzione piu' completa per
realizzare un sito di Disaster Recovery con
il database relazionale Oracle.
L'utilizzo della tecnica di restore database flashback consente significativi risparmi di tempo nel ripristinare
il secondary database.
Il test di un sito secondario in una configurazione di Disaster Recovery
e' sempre impegnativo.
Dopo un test di DR di tipo distruttivo (READ/WRITE) e' necessario ripristinare i
contenuti della base dati secondaria.
Normalmente si utilizza un backup/restore ma questo, per basi dati di gradi dimensioni,
richiede molto tempo.
Inoltre durante tutto il tempo del ripristino la base dati secondaria
non e' utilizzabile come DR (la letteratura consiglia 2 secondari se richiesto dagli SLA).
L'utilizzo del flashback consente significativi risparmi di tempo nel ripristinare
il secondary database rendendo disponibile il sito di DR molto prima che con un
normale restore.
Normalmente dopo un test distruttivo su un'istanza secondaria di Data Guard
e' necessario effettuare un backup/restore partendo dalla produzione.
Se la quantita' di modifiche e' limitata si puo' utilizzare il flashback
per tornare indietro.
Con il flashback il tempo di rientro e' significativamente piu' basso ma
l'operativa e' un po' (leggi molto) piu' complessa.
La complessita' comunque ricade sul DBA e sul sito secondario,
quindi e' accettabile.
I comandi necessari sono:
Primary server:alter system set log_archive_dest_state_2=defer; select max(sequence#) from v$log_history;Il risultato dell'ultima select va salvato come riferimento per i successivi controlli. Secondary server:alter system set db_recovery_file_dest=’/oradata_11p_old/flash’ scope=spfile; alter system set db_recovery_file_dest_size=10G scope=spfile; alter database recover managed standby database cancel; shutdown immediate startup mount alter database flashback on; create restore point base001 guarantee flashback database; alter database activate standby database; alter database open shutdown normal startup*--- TEST DR ---* Possono essere effettuati tutti i test sul database di DR che e' aperto in lettura e scrittura. I due database (primario e secondario) sono entrambe attivi e le applicazioni debbono puntare al database corretto. ATTENZIONE a non puntare al DB di produzione dai sistemi di test del DR !!! *--- Fine TEST ---* Secondary server:shutdown immediate startup mount force flashback database to restore point base001; drop restore point base001; alter database flashback off; alter database convert to physical standby; shutdown immediate startup nomount alter database mount standby database; alter database recover managed standby database disconnect from session;Primary server:alter system set log_archive_dest_state_2='enable'; alter system switch logfile;Ora vanno confrontati gli SCN e le date dei redo log. Se tutto e' corretto il secondary riprende l'applicazione dei redo e si allinea al primary.
Se il DR viene tenuto su a lungo o sono state eseguite attivita' significative (batch pesanti) il flashback fallisce ed e' necessario ripristinare il secondario con il metodo tradizionale (backup/restore da produzione o da secondario).
Nota ufficiale [ID 805438.1]: How To Open Physical Standby For Read Write Testing and Flashback
Nel caso di utilizzo di DG Broker e' possibile seguire questo documento.
Altri documenti di questo tipo su questa pagina.
Titolo: Utilizzare il database Flashback con Oracle Data Guard
Livello: Hack
Data:
31 Ottobre 2012 - Halloween
Versione: 1.0.0 - 31 Ottobre 2012
Autore: mail [AT] meo.bogliolo.name