Dopo una recente interruzione di corrente nel nostro sito DR, ho scoperto che uno standby lì aveva smesso di applicare i log. Apparentemente nei registri di ripristino archiviati c'era una transazione che è cresciuta in un file di dati ma il disco nel sito di standby non aveva spazio su disco sufficiente per consentire il completamento della transazione. Quindi lo standby ha terminato il ripristino gestito, come dovrebbe.
Normalmente conserviamo i registri di ripristino archiviati per 7 giorni. Sfortunatamente, quando ho scoperto questa situazione, erano trascorsi 15 giorni e i registri di ripristino archiviati erano "mancanti". Senza i registri di ripristino archiviati da applicare, l'unica soluzione era ricostruire il database da zero. Questo database ha una dimensione di circa 7 TB, quindi ricostruire da zero non è un affare banale.
Il primario è un database RAC 11.2.0.2 a 3 nodi in esecuzione su Linux. Lo standby è un database RAC a due nodi, ovviamente le stesse versioni Oracle e OS.
Ecco come abbiamo realizzato la ricostruzione dello standby:
- Abbiamo messo il database primario in modalità di backup a caldo e abbiamo eseguito uno snapshot del database basato su disco.
- L'istantanea è stata copiata su un supporto esterno. Nota:la spedizione attraverso la WAN richiedeva troppo tempo.
- Il supporto esterno è stato trasferito manualmente al sito di DR.
- Il LOG_ARCHIVE_DEST_STATE_n per lo standby è stato impostato su DEFER.
- Il database in standby è stato eliminato dalla configurazione di DG Broker: REMOVE DATABASE standby PRESERVA DESTINATIONS;
- I punti di montaggio del database in standby sono stati cancellati. Dopotutto, il database era sostanzialmente inutile a questo punto.
- Sono stati creati nuovi punti di montaggio e lo snapshot è stato scritto sul disco nel sito di ripristino di emergenza.
- Dopo che i trasferimenti di file sono stati completati (circa 5 giorni), abbiamo detto al nostro spazio di archiviazione di aggiornare lo snapshot nel sito di ripristino di emergenza con uno snapshot più aggiornato. Questo è stato eseguito sulla WAN poiché sono state inviate solo le modifiche, che era molto, molto più piccola del database.
- È stato creato un controlfile in standby: ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/dir/path';
- Per semplificare le cose, volevamo utilizzare uno standby a istanza singola fino a quando non l'abbiamo installato e funzionante. Quindi abbiamo creato un PFILE dal RAC SPFILE di standby e quindi abbiamo utilizzato un editor di testo per modificare il file dei parametri per rimuovere eventuali parametri RAC-aware. Abbiamo rimosso CLUSTER_DATABASE, impostato un parametro UNDO_TABLESPACE specifico dell'istanza da utilizzare per tutte le istanze "*.", rimosso i parametri THREAD, ecc. Il nostro normale database di standby ha due istanze, STANDBY1 e STANDBY2. Nel nodo 1, inseriamo il pfile in $ORACLE_HOME/dbs/initstandby.ora invece di initstandby1.ora in modo che il database a istanza singola possa trovare il suo file di parametri. Abbiamo fatto qualcosa di simile per il file della password.
- Abbiamo copiato il file di controllo in standby dal passaggio 9 sui file di controllo nello snapshot del database.
- Con il file pfile e pswd in atto per un database a istanza singola, abbiamo eseguito STARTUP MOUNT.
- Abbiamo creato tutti i registri di ripristino in standby di cui avremmo bisogno. Nel nostro caso, il primario ha anche registri di ripristino in standby per facilitare le operazioni di passaggio e i registri di ripristino in standby del primario non facevano parte dello snapshot. Quindi abbiamo dovuto rimuovere le SRL che non facevano il viaggio.
- Nel principale, imposta LOG_ARCHIVE_DEST_STATE_n su ENABLE.
- Nelle istanze primarie, eseguito ALTER SYSTEM SWITCH LOGFILE;
- Verificato nel registro degli avvisi sia del primario che di quello di standby che lo standby stava ricevendo i log, ovvero verificato che il trasporto dei log funzionasse.
- Attivato in standby gestito:ALTER DATABASE RECOVER GESTITO DATABASE IN STANDBY DISCONNESSIONE DALLA SESSIONE;
- Verificato nel registro degli avvisi dello standby che i registri erano stati applicati, ovvero che l'applicazione verificata ora funzionava.
A questo punto, avevamo un database di standby attivo e funzionante. Abbiamo creato una semplice tabella nella tabella principale e vi abbiamo inserito una riga di dati, eseguito nuovamente i cambi di registro, quindi abbiamo aperto lo standby in modalità SOLA LETTURA per verificare che la transazione sia stata riprodotta in standby come dovrebbe. Una volta che siamo stati soddisfatti del funzionamento del database di standby, è necessario trasformarlo in un database RAC. Bene, tutto è già pronto perché questo sia un database RAC perché lo era una volta. Per completare il lavoro, abbiamo semplicemente arrestato il database di standby a istanza singola (SHUTDOWN ABORT) in SQL*Plus e quindi abbiamo utilizzato srvctl per avviare lo standby come database RAC:
srvctl start database -d standby -o mount
L'unica cosa rimasta a questo punto era aggiungere nuovamente lo standby alla configurazione DG Broker (in DGMGRL): ADD DATABASE standby
Quando è successo per la prima volta, ero preoccupato per come sarebbe andato essere un database così grande. Nessuna delle operazioni precedenti dipende dalle dimensioni, a parte la copia dei file su e dal supporto. Ma è andato tutto bene.
Per assicurarci di non imbatterci in questa situazione in futuro, abbiamo aggiunto avvisi al nostro Oracle Enterprise Manager Grid Control. Ora riceverò un avviso di AVVISO quando la spedizione del registro o l'applicazione del registro sono 12 ore indietro e un avviso CRITICO quando sono indietro di 24 ore. Questo dovrebbe darci tutto il tempo per risolvere eventuali problemi prima che i registri di ripristino archiviati vengano rimossi automaticamente dopo 7 giorni, o almeno, modificare il processo in modo che contenga più giorni di registri di ripristino archiviati fino a quando non risolviamo la situazione.
