Procedura per risolvere i problemi di replica o sincronizzazione del database in Prime Network

Introduzione

In questo documento viene descritta una procedura dettagliata per risolvere i problemi di replica o sincronizzazione del database in Prime Network quando il database in standby del database primario viene ricreato.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Utilizzare questa procedura per ricreare il database secondario solo se SWITCHOVER_STATUS del database primario è in uno spazio vuoto non risolvibile.
• Verificare che il database primario sia in modalità READ WRITE e che il database secondario sia in modalità READ ONLY o READ ONLY WITH APPLY.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Prime Network release 3.9 e successive
• Oracle Database release 11G

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

1. Utilizzare questo comando per conoscere switchover_status del database primario:

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
UNRESOLVABLE GAP 

Nota: Lo switchover Geo HA di Prime Central non funziona correttamente e lo stato del sistema Geo HA di Prime Central e/o del ruolo del database risulta danneggiato (sia in modalità di standby che primaria). Sarà quindi necessario ricostruire il sistema principale o secondario in base all'ultimo stato attivo/standby.

Nota: In tutti gli altri casi, aprire SR con Cisco TAC per risolvere il problema di replica del database.

2. Utilizzare questo comando per conoscere la modalità corrente del database primario e secondario:

 SQL> select open_mode from v$database;  

Problema

Errore di Prime Network Database Replication.

L'applicazione Prime Network crea eventi di sistema che notificano tali errori, disponibili nel client GUI di Event Vision.

Risoluzione dei problemi

Prima di procedere con la risoluzione dei problemi, eseguire le operazioni di base seguenti:

1. Verificare i problemi relativi alla connettività di rete e/o alla latenza tra il gateway di rete principale e secondario.

2. Per individuare eventuali errori ORA correlati al database, controllare i seguenti log del database sul database primario:

<database_home_directory>/diag/rdbms/anadb/anadb/trace/alert_anadb.log

3. Controllare lo stato open_mode, current_scn e switchover sul database primario e secondario.

SQL> select open_mode from v$database;
SQL> select current_scn from v$database;
SQL> select switchover_status from v$database;

4. La causa principale della replica del database può essere un problema di comunicazione di rete tra il gateway di rete principale primario e secondario, un database danneggiato o errori simili correlati al database.

Soluzione

Eseguire la procedura di ripristino del database sul gateway di rete principale e secondario:

Passaggio 1. I processi di backup pianificati correnti conservano diversi giorni di file di log di archivio nel file system. Per evitare di rimuovere i file di log di archivio, questa riga in backup_daily.sh, backup_high_daily.sh, backup_week.sh e backup_high_week.sh è commentata:

Cambia delete noprompt archivelog fino a ora ... in #delete noprompt archivelog fino a ora ...

Nota: Questi script '.sh' sono di proprietà dell'utente oracle e si trovano nella directory $ORACLE_HOME/ana_scripts.

Passaggio 2. Sul database primario, eseguire il login come sysdba ed individuare il numero di redo file sul sistema ed eseguire questo comando:

SQL> select member from v$logfile;

Per ogni log fine eseguire questo comando. Se il comando precedente ha restituito 6 righe, eseguire il comando successivo 6 volte.

SQL>alter system switch logfile;

Passaggio 3. Sul database in standby, accedere come sysdba e creare pfile da spfile:

SQL>create pfile='$ORACLE_HOME/dbs/ana_sb_init.ora' from spfile;

Passaggio 4. In Standby, eseguire il login come sysdba e individuare il percorso della directory del file di dati, i pezzi di backup, i redo log e i file di log di archivio. A tale scopo, è possibile utilizzare i seguenti comandi:

Per trovare i file di dati:

SQL> select name from v$datafile;

Per trovare i file di backup:

rman target /
RMAN> list backup;

Per trovare i redo log file:

 SQL> select member from v$logfile;

Per trovare archiveLog:

SQL> show parameter log_archive_dest_1;

Chiudere il database:

sqlplus / as sysdba
SQL> shutdown immediate;

Passaggio 5. Eliminare tutti i file di dati, le parti di backup, i redo log file e i file di log di archivio dalle directory corrispondenti (percorso trovato nel Passaggio 4.).

Quindi riavviare nomount con il file pfile creato al punto 3:

sqlplus / as sysdba
SQL>startup nomount pfile='$ORACLE_HOME/dbs/ana_sb_init.ora;

Passaggio 6. Sul database primario creare una copia di tutti i backup originali nella cartella di backup e memorizzarli in un'altra posizione.

Passaggio 7. Sul database primario, connettersi a RMAN e utilizzare delete backup per rimuovere tutti i backup fisici dal file system.

#rman target /
RMAN>delete backup;

Passaggio 8. Sul database primario, connettersi a RMAN ed eseguire un backup completo del database, del control file in standby e del log di archivio in questo ordine. Eseguire i seguenti comandi:

#rman target /
RMAN>backup database;
RMAN>backup format '$BACKUP_DIR/Control%U' current controlfile for Standby;
RMAN>backup archivelog all;

Nota: $BACKUP_DIR è la cartella di backup corrente trovata con il backup dell'elenco in precedenza e il file verrà chiamato Control%U in futuro. Non è una variabile.

Passaggio 9. Nel database primario connettersi a RMAN e utilizzare il backup dell'elenco per individuare l'SCN del backup per il campo di controllo in standby creato nel passaggio 8. Cercare il file con il formato del nome $BACKUP_DIR/Control%U.

Tipo di chiave BS Dimensione LV Tipo di dispositivo Tempo trascorso per il completamento

— — — — — —

2358 DISCO PIENO 1,09 M 00:00:04 21-GEN-14

Chiave BP: Stato 2358: DISPONIBILE compresso: Etichetta YES: TAG20140121T162311

Nome pezzo: /export/home/oracle/backup/Control9nouks3f_1_1

File di controllo standby incluso: SCN Ckp: 164541747 Tempo di clock: 21-GEN-14

Nota: In questo esempio, il backup del control file in standby è /export/home/oracle/backup/Control9nouks3f_1_1. Nella riga sotto il nome di questo file viene visualizzato "Ckp SCN: 164541747". Verrà utilizzato il numero "164541747" nel blocco di esecuzione duplicazione al passaggio 13.

Passaggio 10. Nel database primario eseguire il tar di tutti i backup creati nel passaggio 8. Come utente root eseguire il SCP del file tar nella cartella di backup nel database in standby.

Passaggio 11. Accesso al database in standby come utente root e utilizzo di chown per modificare la proprietà del file tar in oracle:dba. Quindi, tornare a oracle(su - oracle) e annullare la frammentazione del file tar.

Passaggio 12. Su login gateway primario come utente di rete principale e cd nella directory ~/principale ed eseguire questo comando per ottenere la password sys:

./runRegTool.sh –gs 127.0.0.1 get 127.0.0.1 persistency/general/EmbeddedDBSystemPass

Nota: La password sys restituita verrà utilizzata nel passaggio successivo per connettersi al database in standby dal database primario.

Passaggio 13. Sul database primario connettersi al database di destinazione (primario) e quindi al database ausiliario (standby). Eseguire quindi il blocco di esecuzione duplicato per creare il database in standby:

#rman target /
RMAN>connect auxiliary sys/$sys_pwd@ANADB_SB
RMAN>run {
set until scn $SCN_NUMBER;
duplicate target database
for Standby
dorecover
spfile
set "db_unique_name"="anadb_sb"
set LOG_ARCHIVE_DEST_2="Service=anadb ASYNC LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
database_unique_name=anadb"
set FAL_CLIENT="anadb_sb"
set FAL_SERVER="anadb"
set log_file_name_convert="$REDO","$REDO"
nofilenamecheck;
}

Nota: $sys_pwd è la password sys ottenuta nel passaggio 12. $SCN_NUMBER nel blocco di esecuzione è ottenuto nel passaggio 9. come esempio. $REDO è il percorso del redo log seguito da /.

Passaggio 14. Una volta completato il blocco di esecuzione nel passaggio 13, accedere al database in standby come sysdba ed eseguire questi comandi per attivare il database in standby in modalità di sola lettura, quindi in sola lettura con la modalità di applicazione:

sqlplus / as sysdba
SQL>shutdown immediate;
SQL>startup nomount;
SQL>alter database mount Standby database;
SQL>recover managed Standby database using current logfile disconnect from session;
SQL>recover managed Standby database cancel;
SQL>alter database open read only;
SQL>recover managed Standby database using current logfile disconnect from session;

Passaggio 15. Dopo la verifica sul database primario, rimuovere il commento da questa riga in backup_daily.sh,backup_high_daily.sh, backup_week.sh e backup_high_week.sh:

Cambia #delete noprompt archivelog fino a ora ... per eliminare noprompt archivelog fino a ora ...

Verifica

Verifica del database sul gateway di rete principale e secondario:

1. Verificare che il numero e i nomi dei redo log file siano gli stessi nel database primario e in standby.

2. Verificare che il numero e le dimensioni dei file di dati nel database primario e in standby siano uguali.

3. Utilizzare questo comando sia sul database primario che su quello in standby per mostrare che l'SCN corrente sul database in standby può raggiungere l'SCN sul database primario:

sqlplus / as sysdba
SQL>select current_scn from v$database;

4. Verificare che open_mode del database primario sia READ WRITE e READ ONLY WITH APPLY nel database in standby.

sqlplus / as sysdba
SQL>select open_mode from v$database;

5. Verificare che switchover_status del database primario sia TO STANDBY e NOT ALLOWED on Standby:

sqlplus / as sysdba 
SQL>select switchover_status from v$database;

6. Convalidare il trasferimento dei log di archivio

Nel database primario:

SQL> alter system switch logfile;

Nel database secondario:

Verificare che in ~/arch sia stato creato un nuovo file.

7. Verificare che l'errore di replica del database non venga visualizzato nell'interfaccia utente grafica di Event Vision (nei prossimi 20 minuti).