Procédure pour reconstruire la base de données active ou de réserve au central principal dû à hors du sync

Introduction

Ce document décrit une procédure pas à pas pour résoudre le problème de réplication de base de données ou de synchronisation dans le réseau principal en reconstruisant la base de données de réserve de la base de données primaire.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Employez cette procédure pour reconstruire la base de données secondaire seulement si SWITCHOVER_STATUS de la base de données primaire est dans l'ÉCART INSOLUBLE ou la DESTINATION DÉFECTUEUSE.
• Assurez-vous que la base de données primaire est dans WRITEand LU la base de données que secondaire est dans WRITEmodes LU.
• Assurez-vous que vous identifiez la passerelle correcte/base de données centrales principales primaires et secondaires.

  

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Version 1.2 centrale principale et en haut
• Release de la base de données 11G d'Oracle

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales

1. Utilisez cette commande de connaître le switchover_status de la base de données primaire :

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

Remarque: Le basculement central principal de Geo ha échoue abruptement laissant le système central principal de GEO ha et/ou état de rôle de base de données corrompu (primay ou standby) et alors vous devez reconstruire primaire ou secondaire selon dernier état actif/de réserve.

Remarque: Pour tous autres cas, ouvrez le SR avec Cisco TAC pour résoudre le problème de réplication de base de données.

2.  Utilisez cette commande de connaître le mode courant de base de données primaire et secondaire :

SQL> select open_mode from v$database; 

3.  Utilisez cette commande de connaître ORACLE_SID de la base de données primaire et secondaire :

    Sur la passerelle principale de l'utilisateur d'oracle :

echo $ORACLE_SID -> output should be “primedb”

    Sur la passerelle secondaire de l'utilisateur d'oracle :

echo $ORACLE_SID -> output should be “primstdb”

Problème

Le commutateur de GEO ha et/ou la procédure centraux principaux de Basculement/restauration échoue quand les databses actifs et de réserve deviennent hors du sync entre eux. Ceci a comme conséquence les databses primaires et de réserve à devenu actif ou de réserve en même temps.

Dépannez

Avant que vous suiviez la solution vous pouvez exécuter les étapes trobleshooting de base :

1. Vérifiez les questions connexes de connexion réseau et/ou de latence entre les serveurs centraux principaux primaires et secondaires.

2. Vérifiez ce login de base de données primaire pour trouver toutes les erreurs ORA associées par base de données :

     

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

3.  Vérifiez l'état d'open_mode, de current_scn et de basculement sur la base de données primaire et secondaire. 

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

4. La cause principale pour la réplication de base de données en grande partie pourrait être betwee de question de communication réseau primaire et le fichier central principal secondaire, la base de données corrompue ou la base de données similary ont associé des erreurs.

Solution

Étape 1. Vérifiez l'ORACLE_SID sur la passerelle primaire et secondaire/bases de données.

Sur la passerelle principale/base de données ORACLE_SID = primedb

Sur la passerelle/base de données secondaires ORACLE_SID = primstdb

Si, ORACLE_SID sur de passerelle primaire ou secondaire n'est pas comme cité précédemment, utilisez cette commande de configurer le SID correct :

setenv ORACLE_SID = <value>

Remarque: Ici le <value > = primedb ou primstdb est basé sur primaire ou secondaire.

Étape 2. Sur la base de données active et de réserve ouvrez une session comme sysdba et trouvez le chemin du répertoire au datafile et refaites les logs et les fichiers journal d'archives.

Servez-vous de ces commandes :

Pour trouver les datafiles :

SQL> select name from v$datafile;

  

Pour trouver les fichiers journal de refaire :      

                          

SQL> select member from v$logfile;

Pour trouver le log d'archives :       

SQL> show parameter log_archive_dest_1;

Étape 3. Pour reconstruire la base de données, exécutez ce script en syntaxe appropriée après que vous identifiiez le scénario correct décrit dans l'étape 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]

Remarque: Le script est copié sous le répertoire $ORACLE_BASE/standby et doit s'exécuter en tant qu'utilisateur d'oracle.

Étape 4. Identifiez n'importe quel scénario avec l'état actuel de votre installation et poursuivez en conséquence :

Remarque: Comme exemple on le suppose que HA1 est passerelle principale/base de données et HA2 est passerelle/base de données secondaires

Scénario 1 : HA1 est en activité et doit reconstruire la base de données de réserve sur HA2. Servez-vous de ces paramètres et exécutez le script mentionné dans l'étape 3. sur 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;'
ORACLE_DATA_FILES_LOCATION = output of ‘select name from v$datafile;'
REDO_LOG_LOCATION = output of ‘select member from v$logfile;’

Scénario 2 : HA2 est en activité et doit reconstruire la base de données de réserve sur HA1. Utilisez ces paramètres et exécutez le script mentionné dans l'étape 3. sur 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 of ‘show parameter log_archive_dest_1;'
ORACLE_DATA_FILES_LOCATION = output of ‘select name from v$datafile;'
REDO_LOG_LOCATION = output of ‘select member from v$logfile;’

Étape 5. Employez cette procédure pour découvrir <SYSTEM_PASSWD> :

le su - perfection sur HA1 ou HA2

installent d'Embedded_SYSTEM_PASS= de grep/conf/.db.conf   

Par exemple s'il a Embedded_SYSTEM_PASS=90f8006cd6bc0dde, puis :

• Javas - déchiffrage 90f8006cd6bc0dde installent de cp/utils/encryptionUtil.jar EncodeDecode. 
• Chaîne centrale principale de sortie de retours qui est utilisée comme SYSTEM_PASSWD dans l'étape 4.

Vérifiez

Vérification de base de données sur la passerelle de réseau principale primaire et secondaire :

1. Vérifiez que le nombre et les noms de refont des fichiers journal sont même sur la base de données active et de réserve.

2. Vérifiez que le nombre et la taille de datafiles sur la base de données active et de réserve sont même.

3. Utilisez cette commande sur la base de données active et de réserve de prouver que le courant SCN sur la base de données de réserve peut rattraper avec le scn sur la base de données primaire :

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

4. Vérifiez que la base de données active de database_roleof est PRIMAIRE et la base de données de réserve est LOGICAL_STANDBY.

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

5. Vérifiez que l'open_mode de la base de données active est LECTURE/ÉCRITURE et LU SEULEMENT AVEC APPLIQUEZ sur la base de données de réserve.

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

6. Vérifiez que le switchover_status de l'Active est AU STANDBY et EST AUTORISÉ sur la base de données de réserve :

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

7. Validez que les logs d'archives obtiennent transféré :

Sur Activedatabase :

SQL> alter system switch logfile;

Sur la base de données de réserve :

    Vérifiez pour s'assurer qu'un nouveau fichier est créé dans ~/arch