Procedura per ricostruire il database attivo o in standby in Prime Central a causa di una mancata sincronizzazione

Introduzione

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

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.
• Accertarsi di identificare correttamente il gateway/database primario e secondario di Prime Central.

  

Componenti usati

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

• Prime Central release 1.2 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; 

3.  Utilizzare questo comando per conoscere ORACLE_SID del database primario e secondario:

    Su gateway primario da utente Oracle:

echo $ORACLE_SID -> output should be “primedb”

    Su gateway secondario da utente Oracle:

echo $ORACLE_SID -> output should be “primstdb”

Problema

Lo switch Prime Central GEO HA e/o la procedura di failover/failback non riescono quando i database attivi e in standby non sono sincronizzati tra loro. In questo modo, sia il database primario che quello in standby diventano contemporaneamente attivi o in standby.

Risoluzione dei problemi

Prima di seguire la soluzione, è possibile eseguire le operazioni di base per la risoluzione dei problemi:

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 l'accesso primario al database:

     

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

3.  Verificare 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 potrebbe essere principalmente un problema di comunicazione di rete tra il database primario e secondario di Prime Central, un database danneggiato o errori correlati a database simili.

Soluzione

Passaggio 1. Verificare ORACLE_SID sul gateway/database primario e secondario.

Sul gateway/database primario ORACLE_SID = primedb

Su gateway secondario/database ORACLE_SID = primdtdb

Se ORACLE_SID su un gateway primario o secondario non corrisponde a quanto indicato in precedenza, utilizzare questo comando per configurare il SID corretto:

setenv ORACLE_SID = <value>

Nota: Qui <value > = primedb o pristdb si basa su primario o secondario.

Passaggio 2. Eseguire l'accesso al database attivo e in standby come sysdba e individuare il percorso della directory del file di dati, nonché i redo log e i log di archivio.

Utilizzare i seguenti comandi:

Per trovare i file di dati:

SQL> select name from v$datafile;

  

Per trovare i redo log file:      

                          

SQL> select member from v$logfile;

Per trovare il log di archivio:       

SQL> show parameter log_archive_dest_1;

Passaggio 3. Per ricreare il database, eseguire questo script con la sintassi corretta dopo aver identificato lo scenario corretto descritto nel passaggio 4.

sh PCoracleADG.ksh [PRIMARY] [STANDBY] [DB_TO_BE_DROPPED] [SYSTEM_PASSWD] [ORACLE_BASE] 
[ORACLE_USER] [ARCHIVED_LOG_LOCATION] [ORACLE_DATA_FILES_LOCATION] [REDO_LOG_LOCATION]

Nota: Lo script viene copiato nella cartella $ORACLE_BASE/standby e deve essere eseguito come utente oracle.

Passaggio 4. Identificare qualsiasi scenario con lo stato corrente dell'impostazione e procedere di conseguenza:

Nota: Ad esempio, si presume che HA1 sia il gateway/database primario e HA2 il gateway/database secondario

Scenario 1: HA1 è attivo e deve ricompilare il database in standby su HA2. Utilizzare questi parametri ed eseguire lo script indicato nel passaggio 3 su HA2.

PRIMARY = primedb
STANDBY = primstdb
DB_TO_BE_DROPPED = primstdb
SYSTEM_PASSWD = use Step 5
ORACLE_BASE = /orahome/oracle
ORACLE_USER = oracle
ARCHIVED_LOG_LOCATION = output of ‘show parameter log_archive_dest_1;&rsquo
ORACLE_DATA_FILES_LOCATION = output of ‘select name from v$datafile;&rsquo
REDO_LOG_LOCATION = output of ‘select member from v$logfile;’

Scenario 2: HA2 è attivo e deve ricompilare il database in standby su HA1. Utilizzare questi parametri ed eseguire lo script indicato nel passo 3 su HA1.

PRIMARY = primedb

STANDBY = primstdb DB_TO_BE_DROPPED = primedb SYSTEM_PASSWD = use Step 5 ORACLE_BASE = /orahome/oracle ORACLE_USER = oracle ARCHIVED_LOG_LOCATION = output di 'show parameter log_archive_dest_1;&rsquo ORACLE_DATA_FILES_LOCATION = output di 'select name from v$datafile;&rsquo REDO_LOG_LOCATION = output di 'select member from v$logfile;'

Passaggio 5. Per individuare <SYSTEM_PASSWD>, attenersi alla procedura seguente:

su - prime su HA1 o HA2

grep Embedded_SYSTEM_PASS= installazione/conf/.db.conf   

Ad esempio, se ha Embedded_SYSTEM_PASS=90f8006cd6bc0dde, allora:

• java -cp install/utils/encryptionUtil.jar Decodifica decodifica 90f8006cd6bc0dde. 
• Prime Central restituisce una stringa di output utilizzata come SYSTEM_PASSWD nel passaggio 4.

Verifica

Verifica del database sul gateway di rete principale e secondario:

1. Verificare che il numero e i nomi dei redo log file siano uguali nei database attivo e in standby.

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

3. Utilizzare questo comando sia sul database attivo 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 database_roleof Active sia PRIMARY e che il database in standby sia LOGICAL_STANDBY.

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

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

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

6. Verificare che switchover_status sia impostato su STANDBY e NON CONSENTITO nel database in standby:

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

7. Verificare che i log di archivio vengano trasferiti:

Su Activedatabase:

SQL> alter system switch logfile;

Nel database in standby:

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