Dépannage d'Oracle Exadata Database Service sur des systèmes d'infrastructure Exascale

Sur chaque noeud de calcul associé à la configuration Data Guard, rassemblez les fichiers journaux correspondant au problème que vous avez rencontré.

• Fichiers journaux de l'étape d'activation (comme ceux détaillant l'opération de création d'une base de données de secours) ainsi que ceux du système principal ou de secours correspondant.
• Fichiers journaux d'ID de travail d'activation. Exemple : 23.
• Emplacement des fichiers journaux d'activation par étape d'activation et système Exadata (principal ou de secours).
• Fichiers journaux de nom de base de données (db_name ou db_unique_name, selon le chemin du fichier).

Le processus qui effectue la configuration est appelé Data Guard Deployer (DGdeployer). Lors de la configuration de la base de données principale, le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log est créé.

Ce journal contient généralement la cause première de l'échec de la configuration de la base de données principale.

• Le journal principal de l'utilitaire de ligne de commande dbaasapi est /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• L'un des journaux de secours de l'utilitaire de ligne de commande dbaasapi est /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Dans ce journal, recherchez les entrées qui contiennent dg_api.
• L'autre journal de secours est /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Il s'agit du journal de configuration Data Guard.

• Le moteur de déploiement Oracle Cloud crée le fichier /var/opt/oracle/log/<dbname>/ocde/ocde.log. Ce journal contient généralement la cause de l'échec de la création de la base de données de secours.
• L'utilitaire de ligne de commande dbaasapi crée le fichier var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• Le fichier journal de configuration Data Guard est /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• Le processus qui effectue la configuration est appelé DGdeployer. Il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal contient généralement la cause première de l'échec de la configuration de la base de données de secours.
• L'utilitaire de ligne de commande dbaasapi crée le fichier /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Recherchez les entrées qui contiennent dg_api.
• Le journal de configuration Data Guard est /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

Le processus qui effectue la configuration est appelé DGdeployer. Lors de la configuration de Data Guard, il crée le fichier /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Ce journal contient généralement la cause première de l'échec de la configuration de la base de données principale.

Sur chaque noeud des sites principal et de secours, collectez les fichiers journaux du nom de base de données associé (db_name).

• Journal d'alertes de base de données : /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Journal du broker Data Guard : /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• Fichier journal des outils cloud pour Data Guard : /var/opt/oracle/log/<dbname>/odg/odg.log

Le mot de passe saisi afin d'activer Data Guard ne correspond pas au mot de passe administrateur principal pour l'utilisateur SYS. Cette erreur peut survenir lors de l'étape d'activation consistant à valider le site principal.

La base de données n'est peut-être pas en cours d'exécution. Cette erreur peut survenir lors de l'étape d'activation consistant à valider le site principal. Effectuez une vérification sur l'hôte à l'aide de srvctl et de sql pour vous assurer que la base de données est démarrée sur tous les noeuds.

La base de données principale n'a pas pu être configurée. Cette erreur peut être due à des commandes Data Guard non valides ou à l'échec de la reconfiguration du processus d'écoute.

Le portefeuille TDE n'a pas pu être créé. Les fichiers du fichier de clés (portefeuille) Oracle TDE (Transparent Database Encryption) n'ont pas pu être préparés en vue du transport vers le site de secours. Cette erreur peut survenir lors de l'étape d'activation consistant à créer un portefeuille TDE. Un échec à cette étape peut être dû aux éléments suivants :

• Accès impossible aux fichiers de portefeuille TDE
• Création impossible d'une archive contenant les fichiers de portefeuille à l'aide des commandes d'activation

Procédure de dépannage :

1. Assurez-vous que le cluster est accessible. Pour vérifier le statut d'un cluster, exécutez la commande suivante :

   crsctl check cluster -all

2. Si le cluster est arrêté, exécutez la commande suivante pour le redémarrer :

   crsctl start crs -wait

3. Si cette erreur survient alors que le cluster est accessible, consultez les journaux de l'étape de création d'un portefeuille TDE (étape d'activation) pour déterminer la cause et la méthode de résolution de l'erreur.

L'archive contenant le portefeuille TDE n'a probablement pas été transmise au site de secours. Il suffit généralement de faire une nouvelle tentative pour résoudre le problème.

• Les sites principal et de secours peuvent ne pas parvenir à communiquer entre eux pour configurer la base de données de secours. Ces erreurs peuvent survenir lors de l'étape d'activation consistant à configurer la base de données de secours. Pendant cette étape, les configurations sont effectuées sur la base de données de secours, y compris la commande de duplication RMAN de la base de données principale. Pour résoudre ce problème, procédez comme suit :
  1. Vérifiez le statut de connectivité des sites principal et de secours.
  2. Assurez-vous que l'hôte peut communiquer à partir du port 1521 avec tous les autres ports. Vérifiez la configuration réseau, y compris les groupes de sécurité réseau, les listes de sécurité réseau et la configuration de l'appairage à distance de réseaux cloud virtuels (le cas échéant). La meilleure façon de tester la communication entre l'hôte et les autres noeuds consiste à accéder aux bases de données à l'aide de SQL*PLUS à partir de la base de données principale vers la base de données de secours, puis inversement.
• Les processus d'écoute ou les adresses IP virtuelles SCAN ne sont peut-être pas en cours d'exécution. Utilisez le test ci-dessus pour identifier le problème.

causes possibles :

• Les processus d'écoute ou les adresses IP virtuelles SCAN ne sont peut-être pas en cours d'exécution. Vous pouvez vérifier la présence de ce problème à l'aide des commandes suivantes sur n'importe quel noeud de cluster.

  • [grid@exa1-****** ~]$ srvctl status
                scan

  • [grid@exa1-****** ~]$ srvctl status
                  scan_listener

• Les bases de données ne sont peut-être pas accessibles. Pour vérifier la présence de ce problème, essayez de vous connecter à l'aide d'un alias Oracle Net existant.

Procédure de dépannage :

1. En tant qu'utilisateur de système d'exploitation oracle, vérifiez qu'un alias Oracle Net existe pour la base de données Conteneur. Recherchez un alias dans $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   L'exemple suivant présente l'entrée d'une base de données Conteneur nommée db12c :

   cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
   DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
   (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
   (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))

2. Vérifiez que vous pouvez utiliser l'alias pour vous connecter à la base de données. Par exemple, en tant que sysdba, saisissez la commande suivante :

   sqlplus sys@db12c

Une cause possible de cette erreur est que les mots de passe utilisateur SYS ou SYSTEM d'Oracle Database pour la base de données et le portefeuille TDE ne sont peut-être pas identiques. Pour comparer les mots de passe, procédez comme suit :

1. Connectez-vous à la base de données en tant qu'utilisateur SYS et vérifiez le statut TDE dans

   V$ENCRYPTION_WALLET

   .
2. Connectez-vous à la base de données en tant qu'utilisateur SYSTEM et vérifiez le statut TDE dans

   V$ENCRYPTION_WALLET

   .
3. Mettez à jour les mots de passe applicables afin qu'ils correspondent. Connectez-vous à l'hôte du système en tant qu'utilisateur opc et exécutez les commandes suivantes :
   1. Pour modifier le mot de passe SYS, utilisez la commande suivante :

      sudo dbaascli database changepassword --dbname <database_name>

   2. Pour modifier le mot de passe du portefeuille TDE, utilisez la commande suivante :

      sudo dbaascli tde changepassword --dbname <database_name>

Plusieurs messages d'erreur peuvent survenir lors de l'exécution des commandes de permutation, de basculement et de rétablissement. Pour en savoir plus sur ces messages d'erreur, reportez-vous à la documentation Oracle Database.

Remarque

Oracle recommande d'utiliser l'interface de ligne de commande du broker Data Guard (dgmgrl) pour valider les configurations.

1. En tant qu'utilisateur Oracle, connectez-vous à la base de données principale ou de secours avec dgmgrl, et vérifiez la configuration et la base de données :

   dgmgrl sys/<pwd>@<database>
   DGMGRL> VALIDATE CONFIGURATION VERBOSE
   DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
   DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>

2. Reportez-vous à la documentation Oracle Database pour trouver le message d'erreur correspondant. Par exemple :
   • ORA-16766 : Redo Apply est arrêté.
   • ORA-16853 : le décalage d'application a dépassé le seuil défini.
   • ORA-16664 : impossible de recevoir le résultat d'un membre (sous la base de données de secours).
   • ORA-12541 : TNS : aucun processus d'écoute (sous la base de données principale).

Journaux DBAASCLI