Vérifier la configuration

Une fois la configuration de récupération après sinistre terminée, validez immédiatement que la configuration est correcte en effectuant une permutation complète ou en ouvrant le site secondaire pour validation. L'ouverture du site secondaire pour validation n'aura aucune incidence sur le système en cours d'exécution dans le site principal.

Ouvrir le secondaire pour validation

Vous pouvez valider le site de secours sans effectuer de permutation complète en convertissant la base de données de secours en base de secours instantanée. Cela permet de démarrer les serveurs SOA secondaires dans le site de secours et de vérifier le système secondaire. Toute modification effectuée dans la base de données du site de secours alors qu'elle est en mode de secours instantané sera abandonnée une fois qu'elle sera de nouveau convertie en base de secours physique. Les données principales ne sont pas touchées par les validations de site secondaire.

Note :

Cette opération doit être effectuée avec prudence : si la base de données contient des messages ou des composites en attente lorsqu'elle est convertie en cliché, les serveurs SOA du site de secours les traitent au démarrage. Vérifiez qu'il n'y a aucune action en attente dans la base principale lors de la conversion en base de secours instantanée. Sinon, supprimez les enregistrements des tables SOA d'exécution de la base de données de secours après leur conversion en base de données de secours instantanée et avant de démarrer les serveurs SOA du site secondaire. Voir Suppression d'enregistrements des tables d'exécution sans supprimer les tables pour connaître les étapes de validation du site de secours sans effectuer de permutation.

En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard dans l'hôte de la base de données principale et convertissez la base de données secondaire en base de secours instantanée.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilisez la commande show configuration pour vérifier que la conversion a été effectuée correctement.
Vérifiez qu'il n'y a aucune action en attente dans l'environnement secondaire.
S'il existe des actions en attente (transactions, messages) dans la base de données principale lorsque la base de secours est convertie en instantané, les serveurs SOA secondaires essaient de les traiter lorsqu'ils start.You peuvent utiliser le script de troncature SOA pour supprimer les enregistrements des tables d'exécution SOA de la base de données secondaire afin de nettoyer les données d'exécution avant de démarrer les serveurs secondaires. Exécutez cette action avec l'instruction CAUTION; ne tronquez pas les tables de la base principale. Voir Suppression d'enregistrements des tables d'exécution sans supprimer les tables.
S'ils ne sont pas déjà activés, démarrez les systèmes Oracle HTTP Server dans le site secondaire.
Démarrez le serveur d'administration dans le site secondaire.
Démarrez les serveurs gérés secondaires dans le site secondaire.
Utilisez la console ou les scripts WebLogic pour démarrer les serveurs gérés secondaires.
Validez le site secondaire.

Comme il ne s'agit pas d'une permutation et que le site principal est toujours actif, le nom frontal virtuel sera résolu à l'adresse IP de l'équilibreur de charge du site principal, de sorte que tout accès au navigateur sera, par défaut, redirigé vers le site principal actif.

Pour accéder directement aux services SOA du site secondaire, vous devez mettre à jour le fichier /etc/hosts dans un client contrôlé (par exemple, un ordinateur portatif), régler le nom frontal virtuel à résoudre à l'adresse IP de l'équilibreur de charge frontal du site secondaire et exécuter toute validation à partir de ce client.

Note :
Vérifiez que le client utilisé pour les validations n'accède pas au système au moyen d'un mandataire HTTP, car le mandataire HTTP peut continuer à résoudre le nom frontal virtuel avec l'adresse IP de l'équilibreur de charge du site principal, quel que soit le nom figurant dans /etc/hosts du client.

Les clients non Linux peuvent nécessiter une réinitialisation de leur cache DNS local avant qu'un navigateur ne résolve l'adresse IP à l'aide de l'entrée de fichier hôte personnalisée.

Une fois le site secondaire validé, passez à l'étape suivante pour le rétablir au rôle de base de secours.

Note :
La validation du site secondaire peut prendre du temps.
Arrêtez les serveurs gérés et les serveurs d'administration du site secondaire.
Utilisez la console WebLogic secondaire pour arrêter les serveurs gérés et le serveur d'administration du site secondaire.
En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard sur l'hôte de base de données principal et convertissez à nouveau la base de données secondaire en base de secours physique.
Vous aurez besoin de votre mot de passe système et du nom unique de votre base de données principale.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilisez show configuration pour vérifier la conversion.
Rétablir les fichiers /etc/hosts mis à jour.
Si vous avez mis à jour des fichiers /etc/hosts dans un client pour qu'ils pointent vers le site secondaire aux fins de validation, rétablissez-les de sorte que le nom frontal virtuel pointe de nouveau vers l'adresse IP frontale principale.

Note :

ORA-01403 : aucune donnée trouvée ORA-06512 erreurs

Lors de la validation du site secondaire tel que décrit ici (sans effectuer une permutation complète, c'est-à-dire qu'il suffit d'ouvrir la base de secours en mode de secours instantané) "ORA-01403 : aucune donnée trouvée ORA-06512" erreurs peuvent apparaître dans les journaux des serveurs SOA de secours. Ces erreurs sont liées à la tâche d'épuration automatique SOA. Ces erreurs se produisent parce que les tâches de la base de données peuvent avoir des dépendances de rôle de base de données (elles sont définies pour être activées uniquement lorsque la base de données est dans le rôle principal). Il s'agit d'un comportement attendu et souhaité qui empêche l'exécution des travaux deux fois (une fois dans la base principale et une fois dans la base de secours). La tâche d'épuration automatique SOA est définie avec le rôle principal. Elle n'est donc pas affichée dans la vue DBA_SCHEDULER_JOBS lorsque la base de données est en mode de secours instantané. La valeur database_role définie pour chaque tâche est visible dans la vue DBA_SCHEDULER_JOB_ROLE. En résumé, ces erreurs peuvent être ignorées tant qu'elles apparaissent dans le système de secours. La tâche du planificateur pour l'épuration automatique SOA sera exécutée sur la base de données si, et seulement si, l'instance change de rôle pour PRIMARY.

Effectuer une permutation

Une permutation est une opération planifiée où un administrateur rétablit les rôles des deux sites. Après une permutation, le système principal devient secondaire et le système secondaire devient principal. L'exécution d'une permutation entraînera un temps d'arrêt sur le site principal.

Avant d'effectuer une permutation dans une configuration DR hybride SOA, propagez toutes les modifications de configuration en attente. Assurez-vous qu'aucune modification répliquée n'est en attente pour le site secondaire.

Désactivez toute réplication programmée pendant la permutation, car elle peut échouer et interférer avec l'opération de permutation elle-même.
Arrêtez les systèmes Oracle HTTP Server dans le site principal.
Arrêtez les serveurs du site principal.
Utilisez la console ou les scripts du serveur d'administration WebLogic pour arrêter les serveurs WebLogic dans le site principal.

Note :
Le serveur d'administration du site principal peut rester actif pendant la permutation. Toutefois, il est recommandé de l'arrêter lorsque le site est en mode veille, car il est prévu que la configuration du domaine dans le site de secours sera remplacée par la configuration principale au cours du cycle de vie. Si le serveur d'administration est opérationnel pendant que cela se produit, il s'exécutera avec une configuration obsolète.
Permutez la permutation avec le nom DNS frontal.

Effectuez la poussée de DNS requise sur le serveur DNS hébergeant les noms utilisés par le système ou modifiez la résolution de l'hôte de fichier dans les clients pour pointer le nom virtuel frontal du système vers l'adresse IP publique utilisée par l'équilibreur de charge sur le site secondaire.

Pour les scénarios où le DNS est utilisé pour la résolution frontale externe (comme le DNS OCI ou le DNS commercial), vous pouvez utiliser une API pour pousser la modification. Pour voir un exemple qui pousse cette modification dans un DNS OCI, allez à GitHub, par exemple, scripts.

Notez que la valeur de durée de vie de l'entrée DNS aura une incidence sur l'OTR de la permutation : si la durée de vie est élevée (par exemple, 20 min), la modification du DNS prendra ce temps pour être effective dans les clients. L'utilisation de valeurs de durée de vie inférieures accélérera cette opération. Toutefois, cela peut entraîner des frais généraux, car les clients accèderont au DNS plus fréquemment au lieu d'utiliser des noms mis en cache. Une bonne approche consiste à régler la durée de vie à une valeur faible temporairement (par exemple, 1 minute), avant la modification du DNS. Ensuite, effectuez la modification et une fois la procédure de permutation terminée, rétablissez la durée de vie à sa valeur initiale.
En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard dans l'hôte de la base de données principale pour effectuer la permutation de base de données.
Vous aurez besoin de votre mot de passe système et du nom unique de votre base de données principale.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
S'ils ne sont pas déjà opérationnels, démarrez les systèmes Oracle HTTP Server dans le site secondaire (nouveau principal).
Démarrez le serveur d'administration dans le site secondaire (nouveau serveur principal) ou redémarrez le serveur s'il a déjà été démarré.
Le démarrage du serveur d'administration permet la prise en compte des modifications de configuration qui ont été répliquées alors qu'il s'agissait d'une base de secours.
Démarrez les serveurs gérés secondaires dans le site secondaire (nouveau serveur principal).
Utilisez la console ou les scripts WebLogic pour démarrer les serveurs gérés secondaires.