Procédure de résolution du problème de réplication ou de synchronisation de base de données dans Prime Network

Introduction

Ce document décrit une procédure étape par étape pour résoudre le problème de réplication ou de synchronisation de la base de données dans Prime Network lorsque la base de données de secours de la base de données principale est restaurée.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Utilisez cette procédure pour reconstruire la base de données secondaire uniquement si SWITCHOVER_STATUS de la base de données principale se trouve dans l'ÉCART NON RÉSOLU.
• Assurez-vous que la base de données principale est en lecture seule et que la base de données secondaire est en lecture seule ou en lecture seule avec les modes APPLY.

Components Used

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

• Prime Network version 3.9 et ultérieure
• Version Oracle Database 11G

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

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

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

Note: La commutation Prime Central Geo HA échoue brusquement, laissant le système Prime Central GEO HA et/ou l'état du rôle de base de données corrompu (primay ou les deux en veille) et vous devez ensuite reconstruire le système principal ou secondaire en fonction du dernier état actif/en veille.

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

2. Utilisez cette commande pour connaître le mode actuel de la base de données principale et secondaire :

 SQL> select open_mode from v$database;  

Problème

Échec de la réplication de base de données réseau Prime.

L'application Prime Network crée des événements système qui notifient de telles défaillances, disponibles dans le client de l'interface graphique utilisateur Event Vision.

Dépannage

Avant la solution, effectuez les étapes de dépannage de base suivantes :

1. Vérifiez la connectivité réseau et/ou les problèmes liés à la latence entre la passerelle réseau Prime principale et secondaire.

2. Vérifiez ces journaux de base de données sur Primary pour trouver les erreurs ORA liées à la base de données :

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

3. Vérifiez l'état open_mode, current_scn et switchover sur la base de données principale 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 première de la réplication de base de données peut être due à un problème de communication réseau entre la passerelle réseau Prime principale et secondaire, à une base de données corrompue ou à des erreurs similaires liées à la base de données.

Solution

Exécuter la procédure de restauration de la base de données sur la passerelle réseau principale et secondaire Prime :

Étape 1. Les tâches de sauvegarde planifiées actuelles conservent plusieurs jours de fichiers journaux d'archivage dans le système de fichiers. Pour éviter la suppression des fichiers journaux d'archive, cette ligne dans backup_daily.sh, backup_high_daily.sh, backup_hebdomadaires.sh et backup_high_hebdomadaires.sh est commentée :

Modifier delete noprompt archivelog jusqu'à ce que le temps ... à #delete noprompt archivelog jusqu'au temps ...

Note: Ces scripts '.sh' appartiennent à oracle user et se trouvent dans le répertoire $ORACLE_HOME/ana_scripts.

Étape 2. Sur la base de données principale, connectez-vous en tant que sysdba et recherchez le nombre de fichiers de rétablissement sur le système par et exécutez cette commande :

SQL> select member from v$logfile;

Pour chaque journal fin, exécutez cette commande. Si la commande précédente a renvoyé 6 lignes, exécutez la commande suivante 6 fois.

SQL>alter system switch logfile;

Étape 3. Dans la base de données de secours, connectez-vous en tant que sysdba et créez un fichier à partir de spfile :

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

Étape 4. Dans la base de données de secours, connectez-vous en tant que sysdba et recherchez le chemin d'accès au fichier de données, aux éléments de sauvegarde, aux journaux de rétablissement et aux fichiers journaux d'archivage. Pour cela, utilisez les commandes suivantes :

Pour rechercher les fichiers de données :

SQL> select name from v$datafile;

Pour rechercher les fichiers de sauvegarde :

rman target /
RMAN> list backup;

Pour rechercher les fichiers journaux de rétablissement :

 SQL> select member from v$logfile;

Pour rechercher archiveLog :

SQL> show parameter log_archive_dest_1;

Arrêter la base de données :

sqlplus / as sysdba
SQL> shutdown immediate;

Étape 5. Supprimez tous les fichiers de données, les éléments de sauvegarde, les fichiers de journalisation et les fichiers d'archivage des répertoires correspondants (chemin d'accès trouvé à l'étape 4).

Redémarrez ensuite nomount avec le fichier créé à l'étape 3 :

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

Étape 6. Sur la base de données principale, faites une copie de toutes les pièces de sauvegarde d'origine dans votre dossier de sauvegarde et stockez-les à un autre emplacement.

Étape 7. Sur la base de données principale, connectez-vous à RMAN et utilisez delete backup pour supprimer toutes les pièces de sauvegarde physiques du système de fichiers.

#rman target /
RMAN>delete backup;

Étape 8. Sur la base de données principale, connectez-vous à RMAN et effectuez une sauvegarde complète de la base de données, du fichier de contrôle de secours et de l'archivage dans cet ordre. Exécutez ces commandes :

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

Note: Le fichier $BACKUP_DIR est le dossier de sauvegarde actuel trouvé précédemment avec la sauvegarde de liste et le fichier sera appelé Control%U dans le futur. Ce n'est pas une variable.

Étape 9. Sur la base de données principale, connectez-vous à RMAN et utilisez la sauvegarde de liste pour trouver le scn ckp pour le champ de contrôle de secours créé à l'étape 8. Recherchez le fichier au format de nom $BACKUP_DIR/Control%U.

Type de clé BS Taille LV Type de périphérique Temps écoulé Heure de fin

— — — — — —

2358 DISQUE 1,09 M 00:00:04 21-JAN-14

Clé BP : 2358 État : DISPONIBLE Comprimé : Balise OUI : TAG20140121T162311

Nom de la pièce : /export/home/oracle/backup/Control9nouks3f_1_1

Fichier de contrôle de secours inclus : Ckp SCN : 164541747 Durée Ckp : 21 JAN-14

Note: Dans cet exemple, la sauvegarde du fichier de contrôle de secours est /export/home/oracle/backup/Control9nouks3f_1_1. Dans la ligne sous ce nom de fichier, vous voyez « Ckp SCN : 164541747 ». Nous allons utiliser le numéro « 164541747 » dans le bloc d'exécution de duplication à l'étape 13.

Étape 10. Sur la base de données principale, décompressez toutes les pièces de sauvegarde créées à l'étape 8. En tant qu'utilisateur racine SCP, le fichier tar est placé dans le dossier de sauvegarde de la base de données de secours.

Étape 11. Dans la base de données de secours, connectez-vous en tant qu'utilisateur root et utilisez chown pour modifier la propriété du fichier tar en oracle : dba. Ensuite, revenez à oracle(su - oracle) et décompressez le fichier tar.

Étape 12. Sur la passerelle principale, connectez-vous en tant qu'utilisateur réseau principal et cd au répertoire ~/Main et exécutez cette commande pour obtenir le mot de passe sys :

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

Note: Le mot de passe sys renvoyé est utilisé à l'étape suivante pour se connecter à la base de données de secours à partir de la base de données principale.

Étape 13. Sur la base de données principale, connectez-vous à la base de données cible (principale), puis à la base de données auxiliaire (veille). Exécutez ensuite le bloc dupliqué pour créer la base de données de secours :

#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;
}

Note: $sys_pwd est le mot de passe sys que vous avez obtenu à l'étape 12. $SCN_NUMBER dans le bloc d'exécution est obtenu à l'étape 9. par exemple. $REDO est l'emplacement du journal de rétablissement suivi de /.

Étape 14. Une fois le bloc d'exécution à l'étape 13. termine, puis connecte la base de données de secours en tant que sysdba et exécutez ces commandes pour activer la base de données de secours en mode lecture seule, suivie de lecture seule avec le mode d'application :

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;

Étape 15. Après vérification sur la base de données principale, décommentez cette ligne dans backup_daily.sh, backup_high_daily.sh, backup_hebdomadairement.sh et backup_high_hebdomadaires.sh :

Modifiez #delete noprompt archivelog jusqu'à ce que le temps ... pour supprimer noprompt archivelog jusqu'à temps ...

Vérification

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

1. Vérifiez que le nombre et le nom des fichiers de journalisation sont identiques dans la base de données principale et de secours.

2. Vérifiez que le nombre et la taille des fichiers de données sur la base de données principale et de secours sont identiques.

3. Utilisez cette commande à la fois sur la base de données Primaire et de secours pour montrer que la base de données SCN on Standby actuelle peut rattraper la base de données SCN on Primary :

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

4. Vérifiez que le mode open_mode de la base de données principale est LECTURE ÉCRITURE et LECTURE SEULE AVEC APPLICATION sur la base de données de secours.

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

5. Vérifiez que l'état switchover_status de la base de données principale est TO STANDBY et NOT ALLOWED on Standby :

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

6. Valider le transfert des journaux d'archivage

Sur la base de données principale :

SQL> alter system switch logfile;

Sur la base de données secondaire :

Vérifiez qu'un nouveau fichier est créé dans ~/arch.

7. Vérifiez que vous ne verrez plus d'échec de réplication de base de données dans l'interface graphique d'Event Vision à partir de maintenant (dans les 20 prochaines minutes).