Mesure corrective pour les événements du service de base de données

Cet article décrit les correctifs requis pour résoudre les problèmes rencontrés lors de l'utilisation des événements du service de base de données.

Les mesures correctives suivantes sont disponibles :

Rubriques connexes

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Nom d'événement

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Description d'événement

Cet événement est signalé lorsque l'espace libre du système de fichiers invité de la machine virtuelle est inférieur à 10 % (déterminé par la commande df(1) du système d'exploitation) pour les systèmes de fichiers suivants :

  • /
  • /u01
  • /u02
  • /var
  • /tmp

Énoncé du problème

Un ou plusieurs systèmes de fichiers de machine virtuelle invitée ont un espace libre inférieur à 10 %.

Risque

Un espace libre insuffisant dans un système de fichiers de machine virtuelle invitée peut entraîner un échec d'affectation d'espace disque, ce qui peut générer des erreurs et des échecs divers dans les logiciels Oracle (Database, Clusterware, outils en nuage).

Action/réparation

Oracle Cloud et l'agent DCS s'exécutent automatiquement pour épurer les anciens fichiers journaux et les fichiers de suivi créés par les outils en nuage afin de récupérer de l'espace dans le système de fichiers.

Si les utilitaires de récupération automatique d'espace du système de fichiers ne peuvent pas épurer suffisamment les anciens fichiers pour effacer cet événement, effectuez les actions suivantes :

  1. Supprimez les fichiers ou répertoires inutiles créés manuellement ou par des applications ou des utilitaires installés par le client. Les fichiers créés par des logiciels installés par le client ne relèvent pas des utilitaires de récupération automatique d'espace du système de fichiers d'Oracle. La commande suivante du système d'exploitation, exécutée en tant qu'utilisateur root, est utile pour identifier les répertoires qui consomment trop d'espace disque : 
    sudo du -hx <file system mount point> | sort -hr

    Ne supprimez que les fichiers ou répertoires dont vous êtes certain qu'ils peuvent être supprimés en toute sécurité.

  2. Définissez la politique d'épuration automatique à l'aide des outils en nuage. Pour plus d'informations, voir Commandes autologcleanpolicy.
  3. Demande de service ouverte pour recevoir des conseils supplémentaires sur la réduction de l'utilisation de l'espace dans le système de fichiers.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Nom d'événement

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Description d'événement

Un événement de type CRITICAL est créé lorsque le service CRS est détecté comme étant arrêté.

Énoncé du problème

CRS est hors ligne ou en échec.

Risque

Si CRS est hors ligne sur un noeud, celui-ci ne peut pas fournir de services de base de données à l'application.

Action/réparation

  1. Vérifiez si le service CRS a été arrêté par votre administrateur, dans le cadre d'un événement de maintenance planifié ou d'une augmentation ou d'une réduction du stockage local
    1. Les événements d'application de correctifs suivants arrêteront CRS
      1. Mise à jour de GRID
      2. Mise à jour de l'invité
      3. Mise à jour de l'hôte
  2. Si CRS s'est arrêté de manière inattendue, le statut courant peut être vérifié en exécutant la commande crsctl check crs.
    1. Si le noeud ne répond pas, il se peut que le noeud de machine virtuelle soit en cours de redémarrage. Attendez la fin du redémarrage du noeud, CRS sera normalement démarré au moyen du processus init.
  3. Si CRS est toujours hors service, recherchez la cause de la défaillance en vous reportant au fichier alert.log dans /u01/app/grid/diag/crs/<node_name>/crs/trace. Vérifiez les entrées de journal correspondant à la date et à l'heure de l'événement d'arrêt et appliquez les mesures correctives appropriées.
  4. Redémarrez CRS, en exécutant la commande crsctl start crs.
  5. Un redémarrage réussi de CRS génère l'événement de résolution : AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Événement de résolution

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Description de l'événement de résolution

Un événement INFORMATION est créé après le démarrage de CRS.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Nom d'événement

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Description d'événement

Un événement de type CRITICAL est créé lorsque le service CRS (Cluster Ready Service) supprime un noeud de la grappe. Le fichier alert.log de CRS est analysé pour rechercher l'erreur CRS-1632 indiquant qu'un noeud est en cours de suppression de la grappe.

Énoncé du problème

Oracle Clusterware est conçu pour effectuer une expulsion de noeuds en supprimant un ou plusieurs noeuds de la grappe si un problème critique est détecté. Un problème critique peut être un noeud qui ne répond pas à une pulsation de réseau ou de disque, une machine bloquée ou gravement dégradée, ou un processus ocssd.bin bloqué. L'objectif de l'expulsion du noeud est de maintenir le bon état général de la grappe en supprimant les membres non sains.

Risque

Pendant le temps nécessaire au redémarrage du noeud expulsé, celui-ci ne peut pas fournir de services de base de données à l'application.

Action/réparation

Une expulsion de noeud CRS peut être dû à des processus OCSSD (ou démon CSS), CSSDAGENT ou CSSDMONITOR. Cela nécessite de déterminer le processus responsable de l'éviction du noeud et d'examiner les fichiers journaux pertinents. Les causes courantes d'éviction OCSSD sont les défaillances/latences de réseau, les problèmes d'E/S avec les disques votants CSS, une escalade d'arrêt de membre. Les évictions CSSDAGENT ou CSSDMONITOR peuvent être un problème de programmateur de système d'exploitation ou une unité d'exécution bloquée dans le démon CSS. Les fichiers journaux à consulter comprennent le journal des alertes de Clusterware, le journal cssdagent, le journal cssdmonitor, le journal ocssd, le journal lastgasp, les messages /var/log/, les données de CHM/OS Watcher et les détails de la commande opatch lsinventory.

Pour plus d'informations sur la collecte de fichiers, voir Autonomous Health Framework (AHF), Trace File Analyzer (TFA) et ORAchk/EXAchk. Pour plus d'informations sur le dépannage de l'expulsion de noeuds CRS, voir Dépannage des expulsions de noeuds Clusterware (redémarrages).

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Nom d'événement

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Description d'événement

Un événement DOWN est créé lorsqu'un module d'écoute SCAN tombe en panne. L'événement est de type INFORMATION lorsqu'un module d'écoute SCAN est arrêté en raison d'une action de l'utilisateur, par exemple avec les commandes Server Control Utility (srvctl) ou Listener Control (lsnrctl), ou toute action de maintenance Oracle Cloud qui utilise ces commandes, telle que l'exécution d'une mise à jour du logiciel Grid Infrastructure. L'événement est de type CRITICAL si le module d'écoute SCAN tombe en panne de manière inattendue. Un événement DOWN_CLEARED correspondant est créé lors du démarrage d'un module d'écoute SCAN.

Il existe trois modules d'écoute SCAN par grappe nommés LISTENER_SCAN[1,2,3].

Énoncé du problème

Un module d'écoute SCAN est hors service et ne peut pas accepter les connexions d'application.

Risque

Si tous les modules d'écoute SCAN sont hors service, les connexions d'application à la base de données au moyen du module d'écoute SCAN échoueront.

Action/réparation

Démarrez le module d'écoute SCAN pour recevoir l'événement DOWN_CLEARED.

Événement DOWN de type INFORMATION

  1. Si l'événement a été causé par une action de maintenance Oracle Cloud, telle qu'une mise à jour du logiciel Grid Infrastructure, aucune action n'est requise. Le module d'écoute SCAN affecté bascule automatiquement vers une instance disponible.
  2. Si l'événement a été causé par une action de l'utilisateur, lancez le module d'écoute SCAN dès que possible.

Événement DOWN de type CRITICAL

  1. Vérifiez le statut SCAN et redémarrez le module d'écoute SCAN
    • Connectez-vous à la machine virtuelle en tant qu'utilisateur opc et sudo pour l'utilisateur grid : 
      [opc@vm ~] sudo su - grid
    • Vérifiez le statut des modules d'écoute SCAN sur n'importe quel noeud :
      [grid@vm ~] srvctl status scan_listener
    • Démarrez le module d'écoute SCAN :
      [grid@vm ~] srvctl start scan_listener
    • Vérifiez de nouveau le statut des modules d'écoute SCAN sur n'importe quel noeud : Si scan_listener est toujours arrêté, recherchez la cause de la défaillance du module d'écoute SCAN :
      1. Collectez les journaux CRS et du système d'exploitation 30 minutes avant et pendant 10 minutes pour le <hostName> indiqué dans le journal. Notez que l'heure dans les données utiles des événements est toujours indiquée en UTC. Pour la collecte tfactl, ajustez l'heure en fonction du fuseau horaire de la grappe de machines virtuelles. 
        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
      2. Les problèmes de module d'écoute SCAN sont enregistrés :
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Nom d'événement

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Description d'événement

Un événement DOWN est créé lorsqu'un module d'écoute client tombe en panne. L'événement est de type INFORMATION lorsqu'un module d'écoute client est arrêté en raison d'une action de l'utilisateur, par exemple avec les commandes Server Control Utility (srvctl) ou Listener Control (lsnrctl), ou toute action de maintenance Oracle Cloud qui utilise ces commandes, telle que l'exécution d'une mise à jour du logiciel Grid Infrastructure. L'événement est de type CRITICAL lorsqu'un module d'écoute client s'arrête de manière inattendue. Un événement DOWN_CLEARED correspondant est créé lors du démarrage d'un module d'écoute de client.

Il existe un module d'écoute client par noeud, chacun appelé LISTENER.

Énoncé du problème

Un module d'écoute client est arrêté et ne peut pas accepter les connexions d'application.

Risque

Si le module d'écoute client du noeud est arrêté, les instances de base de données du noeud ne peuvent pas fournir de services à l'application.

Si le module d'écoute client est arrêté sur tous les noeuds, la connexion d'une application à une base de données à l'aide du nom SCAN ou de l'adresse IP virtuelle échoue.

Action/réparation

Démarrez le module d'écoute du client pour recevoir l'événement DOWN_CLEARED.

Événement DOWN de type INFORMATION

  1. Si l'événement a été causé par une action de maintenance Oracle Cloud, telle qu'une mise à jour du logiciel Grid Infrastructure, aucune action n'est requise. Le module d'écoute client concerné redémarre automatiquement lorsque la maintenance affectant l'instance Grid Infrastructure est terminée.
  2. Si l'événement a été causé par une action de l'utilisateur, lancez le module d'écoute client dès que possible.

Événement DOWN de type CRITICAL

  1. Vérifiez le statut du module d'écoute client et redémarrez celui-ci.
    • Connectez-vous à la machine virtuelle en tant qu'utilisateur opc et sudo pour l'utilisateur grid :
      [opc@vm ~] sudo su - grid
    • Vérifiez le statut du module d'écoute client sur n'importe quel noeud :
      [grid@vm ~] srvctl status listener
    • Démarrez le module d'écoute du client :
      [grid@vm ~] srvctl start listener
    • Vérifiez de nouveau le statut du module d'écoute client sur n'importe quel noeud pour savoir s'il est toujours arrêté. Recherchez la cause de la défaillance du module d'écoute client :
      1. Utilisez tfactl pour collecter les journaux CRS et du système d'exploitation 30 minutes avant et pendant 10 minutes pour le hostName indiqué dans le journal. Notez que l'heure dans les données utiles des événements est toujours indiquée en UTC. Pour la collecte tfactl, ajustez l'heure en fonction du fuseau horaire de la grappe de machines virtuelles.
        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
      2. Vérifiez le journal du module d'écoute situé sous :
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Nom d'événement

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Description d'événement

Un événement DOWN est créé lorsqu'une instance de base de données tombe en panne. L'événement est de type INFORMATION lorsqu'une instance de base de données est arrêtée en raison d'une action de l'utilisateur, par exemple avec les commandes SQL*Plus (sqlplus) ou Server Control Utility (srvctl), ou toute action de maintenance Oracle Cloud qui utilise ces commandes, telle que l'exécution d'une mise à jour logicielle de répertoire de base de base de données. L'événement est de type CRITICAL lorsqu'une instance de base de données tombe en panne de manière inattendue. Un événement DOWN_CLEARED correspondant est créé lors du démarrage d'une instance de base de données.

Énoncé du problème

Une instance de base de données est arrêtée.

Risque

Une instance de base de données est arrêtée, ce qui peut entraîner une baisse de performance si des instances de base de données sont disponibles sur d'autres noeuds de la grappe ou un arrêt complet si les instances de base de données sur tous les noeuds sont arrêtées.

Action/réparation

Démarrez l'instance de base de données pour recevoir l'événement DOWN_CLEARED.

Événement DOWN de type INFORMATION

  1. Si l'événement a été causé par une action de maintenance Oracle Cloud, telle qu'une mise à jour du logiciel du répertoire de base de la base de données, aucune action n'est requise. L'instance de base de données concernée redémarre automatiquement lorsque la maintenance touchant l'instance est terminée.
  2. Si l'événement a été causé par une action de l'utilisateur, démarrez l'instance de base de données concernée dès que possible.

Événement DOWN de type CRITICAL

  1. Vérifiez le statut de la base de données et redémarrez l'instance de base de données inactive.
    1. Connectez-vous à la machine virtuelle en tant qu'utilisateur oracle :
    2. Définissez l'environnement :
      [oracle@vm ~] . <dbName>.env
    3. Vérifiez le statut de la base de données :
      [oracle@vm ~] srvctl status database -db <dbName>
    4. Démarrez l'instance de base de données :
      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>
  2. Examinez la cause de l'échec de l'instance de base de données.
    1. Vérifier les événements TFA (Trace File Analyzer) pour la base de données :
      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
    2. Consultez le journal des alertes de la base de données sous :
      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Nom d'événement

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Description d'événement

Une corruption de base de données a été détectée sur la base de données principale ou de secours. Le fichier alert.log de la base de données est analysé en cas d'erreurs spécifiques qui indiquent des corruptions de bloc physique, des corruptions de bloc logique ou des corruptions de bloc logique causées par des écritures perdues.

Énoncé du problème

Les corruptions peuvent entraîner des erreurs d'application ou de base de données et, dans le pire des cas, entraîner une perte de données importante si elles ne sont pas traitées rapidement.

Un bloc corrompu est un bloc qui a été modifié de sorte qu'il diffère de ce qu'Oracle Database s'attend à trouver. Les corruptions de bloc peuvent être classées comme physiques ou logiques :

  • Dans une corruption de bloc physique, également appelée corruption du média, la base de données ne reconnaît pas du tout le bloc; le total de contrôle n'est pas valide ou le bloc ne contient que des zéros. Un exemple de corruption de bloc plus sophistiquée est lorsque l'en-tête et le pied de page du bloc ne correspondent pas.
  • Dans le cas d'une corruption de bloc logique, le contenu du bloc est physiquement sain et passe les vérifications du bloc physique; toutefois, le bloc peut être logiquement incohérent. Exemples de corruption de bloc logique : type de bloc incorrect, données incorrectes ou numéro de séquence de bloc de journalisation incorrect, corruption d'un élément de rangée ou d'une entrée d'index, ou corruptions du dictionnaire de données.

Les corruptions de bloc peuvent également être divisées en corruption interblocs et corruption intrabloc :

  • Dans une corruption intrabloc, la corruption se produit dans le bloc lui-même et peut être soit physique, soit logique.
  • Dans une corruption interblocs, la corruption se produit entre les blocs et ne peut être qu'une corruption de bloc logique.

Oracle vérifie les erreurs suivantes dans le fichier alert.log :

  • ORA-01578
  • ORA-00752
  • ORA-00753
  • ORA-00600 [3020]
  • ORA-00600 [kdsgrp1]
  • ORA-00600 [kclchkblk_3]
  • ORA-00600 [13013]
  • ORA-00600 [5463]

Risque

Une panne due à la corruption des données se produit lorsqu'un composant matériel, logiciel ou réseau provoque la lecture ou l'écriture de données corrompues. L'incidence sur le niveau de service d'une panne due à la corruption des données peut varier, allant d'une petite partie de l'application ou de la base de données (jusqu'à un seul bloc de base de données) à une grande partie de l'application ou de la base de données (la rendant essentiellement inutilisable). Si aucune mesure corrective n'est prise rapidement, le temps d'arrêt potentiel et la perte de données peuvent augmenter.

Action/réparation

L'avis d'événement courant se déclenche actuellement sur les corruptions de bloc physique (ORA-01578), les pertes d'écritures (ORA-00752, ORA-00753 et ORA-00600 avec le premier argument 3020) et les corruptions logiques (typiques détectées à partir de ORA-00600 avec le premier argument kdsgrp1, kdsgrp1, kclchkblk_3, 13013 ou 5463).

Il est recommandé d'effectuer les étapes suivantes :

  1. Vérifiez que ces corruptions ont été signalées dans le fichier de suivi alert.log. Enregistrez une demande de service avec le dernier rapport EXAchk, l'extrait du fichier alert.log et le fichier de suivi contenant les erreurs de corruption, l'historique des modifications récentes d'application, de base de données ou de logiciel et tous les journaux de système, de clusterware et de base de données pour la même période. Pour tous ces cas, une collecte TFA doit être disponible et doit être jointe à la demande de service.
  2. Pour plus d'informations sur les recommandations de réparation, voir Note principale relative au traitement des problèmes de corruption dans Oracle Database.

Pour les corruptions physiques ou les erreurs ORA-1578, les notes suivantes seront utiles :

Note :

RMAN peut être utilisé pour récupérer un ou plusieurs blocs de données physiquement corrompus. En utilisant Active Data Guard avec une application en temps réel, la réparation automatique des blocs des corruptions de données physiques aurait été effectuée automatiquement.

Pour les corruptions logiques causées par des pertes d'écriture (ORA-00752, ORA-00753 et ORA-00600 avec le premier argument 3020) sur les bases de données principale ou de secours, elles sont détectées sur la base principale ou avec le processus d'application des données de journalisation de la base de secours. Les notes suivantes seront utiles :

Pour les corruptions logiques (généralement signalées par ORA-00600 avec les arguments kdsgrp1, kclchkblk_3, 13013 ou 5463)

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Nom d'événement

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Description d'événement

Un événement de type CRITICAL est créé si une base de données conteneur ne peut pas archiver le fichier de journalisation en ligne actif ou si elle ne peut pas archiver le fichier de journalisation en ligne actif assez rapidement pour les destinations d'archivage des journaux.

Énoncé du problème

L'instance RAC de la base de données conteneur peut être temporairement ou définitivement bloquée en raison de l'incapacité du processus de journalisation (LGWR) à écrire les tampons de journalisation dans un fichier de journalisation en ligne. Cela se produit parce que tous les journaux en ligne doivent être archivés. Une fois que l'utilitaire d'archivage (ARC) peut archiver au moins un fichier de journalisation en ligne, LGWR pourra reprendre l'écriture des tampons de journalisation dans les fichiers de journalisation en ligne et l'incidence sur l'application sera atténuée.

Risque

Si l'utilitaire d'archivage ne répond plus temporairement, les applications risquent d'être brièvement bloquées lors de la tentative de validation des modifications apportées à la base de données. Si l'utilitaire d'archivage n'est pas restauré, les processus d'application peuvent subir de longs délais de traitement.

Action/réparation

  • Pour déterminer la fréquence horaire de chaque unité d'exécution/instance, voir Script pour rechercher l'historique de changement du fichier de journalisation et rechercher la taille des journaux d'archivage pour chaque instance dans RAC (ID document 2373477.1).
    • Si un seau horaire est supérieur à 12, envisagez de redimensionner les fichiers de journalisation en ligne. Voir l'élément 2 ci-dessous pour les étapes de redimensionnement.
  • Si la base de données ne répond plus temporairement, l'utilitaire d'archivage peut ne pas être en mesure de suivre le fichier de journalisation généré.
    • Vérifiez alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log, pour "All online logs need archiving"; plusieurs événements dans une courte période peuvent indiquer 2 solutions possibles.
      1. Si le nombre de groupes de fichiers de journalisation par unité d'exécution est inférieur à 4, envisagez d'ajouter des groupes de journaux supplémentaires pour atteindre 4, voir le point 1 ci-dessous pour ajouter des étapes de fichier de journalisation.
      2. L'autre solution possible consiste à redimensionner les fichiers de journalisation, voir l'élément 2 ci-dessous pour les étapes de redimensionnement.
  • Pour des directives de dimensionnement avec et sans Data Guard, voir Configurer les fichiers de journalisation en ligne de manière appropriée.
  • Ajoutez un groupe de fichiers de journalisation pour chaque unité d'exécution. La taille du fichier de journalisation supplémentaire doit être égale à celle du journal courant.
    1. Utilisez l'interrogation suivante : 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Ajoutez un nouveau groupe par unité d'exécution avec la même taille que celle des fichiers de journalisation courants.
      alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>
  • Redimensionnez les fichiers de journalisation en ligne en ajoutant des fichiers de journalisation plus volumineux et en supprimant les fichiers de journalisation plus petits.
    1. Utilisez l'interrogation suivante : 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Ajoutez le même nombre de fichiers de journalisation pour chaque unité d'exécution number_of_groups_per_thread existantes. La valeur new_redo_size_in_bytes doit être définie en fonction des consignes de la rubrique Configurer les fichiers de journalisation en ligne de manière appropriée. 
      1. alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
      2. Les fichiers de journalisation initiaux plus petits doivent être supprimés. Un fichier de journalisation ne peut être supprimé que si son statut est inactif. Pour déterminer le statut d'un fichier de journalisation, exécutez la commande select suivante. 
        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        Supprimez les fichiers de journalisation initiaux plus petits :

        alter database drop logfile <group#>;
  • Si la base de données ne répond plus, il se peut que la destination principale et la destination de remplacement de l'archive du journal soient pleines.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Nom d'événement

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Description d'événement

Un événement de type CRITICAL est créé lorsqu'un processus ou une session ne répond plus dans la base de données conteneur (CDB).

Énoncé du problème

Le résolveur de bloqueur a détecté un processus ou un bloc qui ne répond pas et a généré un message d'erreur ORA-32701. En outre, cet événement peut être généré si le processus de diagnostic (DIA0) détecte qu'un processus de base de données critique ne répond plus.

Risque

Un processus ou un bloc qui ne répond pas peut indiquer des problèmes liés aux ressources, au système d'exploitation ou au codage d'application.

Action/réparation

Examinez la cause du bloc de session.

  • Vérifiez les événements TFA de la base de données pour les modèles de message suivants correspondant à la date et à l'heure de l'événement : ORA-32701, "DIA0 : Processus critique de base de données bloqué" ou "DIA0 : Processus critique de base de données en tant que racine". 
    tfactl events -database <dbName> -instance <instanceName>
  • Vérifiez le fichier alert.log associé à l'emplacement suivant : 
    $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
  • Pour ORA-32701 : Un système surchargé peut entraîner une progression lente, ce qui peut être interprété comme un bloc. Le résolveur de blocage peut tenter de résoudre le bloc en mettant fin au processus de blocage final.
  • Pour les messages de processus critique de base de données DIA0 : Vérifiez les lignes de diagnostic connexes indiquant le processus et le motif du bloc.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Nom d'événement

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Description d'événement

Un événement de type CRITICAL est créé s'il existe une sauvegarde de base de données conteneur avec le statut FAILED signalé dans la vue v$rman_status.

Énoncé du problème

Une sauvegarde incrémentielle quotidienne de la base de données conteneur a échoué.

Risque

Un échec de la sauvegarde peut compromettre la capacité à utiliser les sauvegardes pour la restauration/récupération de la base de données. L'objectif de point de récupération (OPR) et l'objectif de délai de récupération (ODR) peuvent être touchés.

Action/réparation

Consultez les journaux RMAN correspondant à la date et à l'heure de l'événement. Notez que l'horodatage de l'événement eventTime est en UTC, ajustez-le si nécessaire en fonction du fuseau horaire de la machine virtuelle.

Pour les sauvegardes gérées par Oracle :

  • La sortie RMAN est disponible sous /opt/oracle/dcs/log/<hostname>/rman.
  • Vérifiez le journal pour tout échec :
    • Si l'échec est dû à un événement externe à RMAN, par exemple, l'emplacement de sauvegarde était plein ou un problème de réseau, résolvez le problème externe.
    • Pour les autres erreurs de script RMAN, collectez les journaux de diagnostic et ouvrez une demande de service.
      dbcli collect-diagnostics -h
      Usage: collect-diagnostics [options]
  Options:
    --components, -c
       Supported components: [all, dcs, crs, acfs, asm, db]
       all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
       dcs -- Collects diagnosis for dcs
       crs -- Collects diagnosis for crs
       acfs -- Collects diagnosis for acfs
       asm -- Collects diagnosis for asm.
       db -- Collects diagnosis for db.
       For multiple parameter values, follow the example as "-c c1 c2"
       Default: [dcs]
    --dbNames, -d
       Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
    --endTime, -et
       End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
    --help, -h
       get help
    --json, -j
       json output
    --objectstoreuri, -ou
       Pre Authenticated Request URI
    --redaction, -r
       Diagnostic logs redaction. Might take longer time with some components.
    --startTime, -st
    Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
  • Si le problème est transitoire ou résolu, effectuez une nouvelle sauvegarde incrémentielle. For more information, see Back Up a Database Using the Console.

Pour les sauvegardes gérées et détenues par le client effectuées par RMAN :

  • Consultez les journaux RMAN pour la sauvegarde.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Nom d'événement

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Description d'événement

Un événement de type CRITICAL est créé lorsqu'un groupe de disques ASM atteint l'espace utilisé à 90 % ou plus. Un événement de type INFORMATION est créé lorsque l'utilisation de l'espace du groupe de disques ASM est inférieure à 90 %.

Énoncé du problème

L'utilisation de l'espace du groupe de disques ASM est égale ou supérieure à 90 %.

Risque

Un espace insuffisant pour le groupe de disques ASM peut entraîner l'échec de la création des bases de données, l'échec de la création des espaces-tables et des fichiers de données, l'échec de l'extension automatique des fichiers de données ou l'échec du rééquilibrage ASM.

Action/réparation

L'espace utilisé du groupe de disques ASM est déterminé par l'exécution de l'interrogation suivante lors de la connexion à l'instance ASM.

sudo su - grid
sqlplus / as sysasm
select 'ora.'||name||'.dg', total_mb, free_mb, 
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;
NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

La capacité des groupes de disques ASM peut être augmentée de la manière suivante :

  1. Ajustez le stockage de la grappe de machines virtuelles pour augmenter la capacité du groupe de disques ASM. Pour plus d'informations, voir Augmenter le stockage d'un système de base de données sur machine virtuelle.

L'utilisation de l'espace de groupe de disques DATA peut être réduite de la manière suivante :

  1. Supprimez les fichiers de données non utilisés et les fichiers temporaires des bases de données. Pour plus d'informations, voir Suppression de fichiers de données.

L'utilisation de l'espace de groupe de disques RECO peut être réduite de la manière suivante :

  1. Supprimez les points de restauration garantis inutiles. Pour plus d'informations, voir Utilisation de points de restauration normaux et garantis.
  2. Supprimez les fichiers de journalisation archivés ou les sauvegardes de base de données déjà sauvegardés en dehors de la zone de récupération rapide (FRA). Pour plus d'informations, voir Gestion de la zone de récupération rapide.