Résolution des événements du service Database

Cet article décrit les corrections nécessaires pour les problèmes rencontrés lors de l'utilisation des événements du service Database.

Les résolutions suivantes sont disponibles :

Rubriques connexes

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Nom d'événement

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Description de l'événement

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

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

Enoncé du problème

Des systèmes de fichiers d'invité de machine virtuelle disposent d'un espace libre inférieur à 10 %.

Risque

Un espace libre insuffisant sur un système de fichiers d'invité de machine virtuelle peut causer l'échec de l'allocation de l'espace disque, ce qui peut entraîner des erreurs et des défaillances générales dans le logiciel Oracle (Database, Clusterware, outils cloud).

Action/Réparation

Oracle Cloud et l'agent DCS s'exécutent automatiquement pour purger les anciens fichiers journaux et fichiers trace créés par les outils cloud afin de récupérer l'espace du système de fichiers.

Si les utilitaires de récupération automatique d'espace de système de fichiers ne peuvent pas purger suffisamment les anciens fichiers afin d'effacer cet événement, effectuez les opérations suivantes :

  1. Enlevez les fichiers et/ou répertoires inutiles créés manuellement ou par les applications ou utilitaires installés par le client. Les fichiers créés par le logiciel installé par le client sont hors de la portée des utilitaires de récupération automatique d'espace de système de fichiers d'Oracle. La commande de système d'exploitation suivante, exécutée en tant qu'utilisateur root, permet d'identifier les répertoires qui consomment trop d'espace disque : 
    sudo du -hx <file system mount point> | sort -hr

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

  2. Définissez la stratégie de purge automatique à l'aide des outils cloud. Pour plus d'informations, reportez-vous à Commandes autoLogCleanPolicy.
  3. Ouvrez la demande de service pour recevoir des conseils supplémentaires sur la réduction de l'utilisation de l'espace du système de fichiers.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Nom d'événement

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Description de l'événement

Un événement de type CRITICAL est créé lorsque CRS (Cluster Ready Service) est repéré comme étant arrêté.

Enoncé du problème

CRS est à l'état Hors ligne ou a échoué.

Risque

Si CRS est hors ligne sur un noeud, ce dernier ne peut pas fournir de services de base de données pour l'application.

Action/Réparation

  1. Vérifiez si CRS a été arrêté par l'administrateur, dans le cadre d'un événement de maintenance programmée, ou d'une augmentation ou d'une réduction du stockage local
    1. Les événements d'application de patches suivants arrêtent 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, vous pouvez consulter le statut en cours en exécutant la commande crsctl check crs.
    1. Si le noeud ne répond pas, le noeud de machine virtuelle est peut-être en cours de redémarrage. Attendez la fin du redémarrage du noeud. CRS sera normalement démarré via le processus init.
  3. Si CRS est toujours arrêté, recherchez la cause de l'échec en vous référant au fichier alert.log figurant dans /u01/app/grid/diag/crs/<node_name>/crs/trace. Consultez les entrées de journal correspondant à la date/l'heure de l'événement d'arrêt et effectuez toutes les actions de résolution nécessaires.
  4. Redémarrez CRS en exécutant la commande crsctl start crs.
  5. Le redémarrage de CRS génère l'événement d'effacement AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Evénement d'effacement

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Description de l'événement d'effacement

Un événement INFORMATION est créé une fois que CRS est démarré.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Nom d'événement

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Description de l'événement

Un événement de type CRITICAL est créé lorsque CRS (Cluster Ready Service) expulse un noeud du cluster. Le fichier alert.log de CRS est analysé à la recherche de l'erreur CRS-1632 indiquant qu'un noeud est en train d'être enlevé du cluster.

Enoncé du problème

Oracle Clusterware est conçu pour expulser les noeuds en les enlevant du cluster si un problème critique est détecté. Le problème critique peut consister en un noeud ne répondant pas via un signal d'activité de réseau ou de disque, une machine bloquée ou très dégradée, ou un processus ocssd.bin bloqué. L'objectif de l'expulsion de noeud est d'enlever les membres en mauvais état afin de maintenir l'état général du cluster.

Risque

Pendant le délai nécessaire au redémarrage du noeud expulsé, ce dernier ne peut pas fournir de services de base de données pour l'application.

Action/Réparation

Une expulsion de noeud CRS peut être causée par des processus OCSSD (ou démon CSS), CSSDAGENT ou CSSDMONITOR. Il est nécessaire de déterminer quel processus a entraîné l'expulsion de noeud et de consulter les fichiers journaux pertinents. Les causes courantes d'expulsion OCSSD sont les pannes/latences réseau, les problèmes d'E/S avec des disques "votants" CSS ou une escalade d'arrêt de membre. Les expulsions CSSDAGENT ou CSSDMONITOR peuvent être dues à un problème de programmateur de système d'exploitation ou à un thread bloqué dans le démon CSS. Vous devez notamment consulter les fichiers journaux suivants : journal d'alertes de clusterware, journal cssdagent, journal cssdmonitor, journal ocssd, journal lastgasp, /var/log/messages, données de CHM/d'OS Watcher et détails d'opatch lsinventory.

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

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Nom d'événement

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Description de l'événement

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

Il existe trois processus d'écoute SCAN par cluster appelés LISTENER_SCAN[1,2,3].

Enoncé du problème

Un processus d'écoute SCAN est arrêté et ne peut pas accepter de connexions d'application.

Risque

Si tous les processus d'écoute SCAN sont arrêtés, les connexions d'application à la base de données via le processus d'écoute SCAN échoueront.

Action/Réparation

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

Evénement DOWN de type INFORMATION

  1. Si l'événement est dû à une action de maintenance Oracle Cloud, telle qu'une mise à jour du logiciel Grid Infrastructure, aucune action n'est requise. Le processus d'écoute SCAN concerné bascule automatiquement vers une instance disponible.
  2. Si l'événement est dû à une action de l'utilisateur, démarrez le processus d'écoute SCAN dès que vous pouvez.

Evénement DOWN de type CRITICAL

  1. Vérifiez le statut du processus d'écoute SCAN, puis redémarrez ce dernier
    • Connectez-vous à la machine virtuelle en tant qu'utilisateur opc et passer à l'utilisateur grid à l'aide de la commande sudo : 
      [opc@vm ~] sudo su - grid
    • Vérifiez le statut des processus d'écoute SCAN sur un noeud :
      [grid@vm ~] srvctl status scan_listener
    • Démarrez le processus d'écoute SCAN :
      [grid@vm ~] srvctl start scan_listener
    • Vérifiez à nouveau le statut des processus d'écoute SCAN sur un noeud. Si le processus d'écoute SCAN scan_listener est toujours arrêté, recherchez la cause de l'échec :
      1. Collectez les journaux de CRS et du système d'exploitation 30 minutes avant et 10 minutes après pour le nom d'hôte <hostName> indiqué dans le journal. L'heure indiquée dans la charge utile d'événement est toujours au format UTC : pour la collecte par tfactl, ajustez l'heure au fuseau horaire du cluster 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 liés au processus d'écoute SCAN sont consigné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 de l'événement

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

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

Enoncé du problème

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

Risque

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

Si le processus d'écoute client est arrêté sur tous les noeuds, les applications qui se connectent à une base de données à l'aide du processus d'écoute SCAN ou de l'adresse IP virtuelle échoueront.

Action/Réparation

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

Evénement DOWN de type INFORMATION

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

Evénement DOWN de type CRITICAL

  1. Vérifiez le statut du processus d'écoute client, puis redémarrez ce dernier.
    • Connectez-vous à la machine virtuelle en tant qu'utilisateur opc et passer à l'utilisateur grid à l'aide de la commande sudo :
      [opc@vm ~] sudo su - grid
    • Vérifiez le statut du processus d'écoute client sur un noeud :
      [grid@vm ~] srvctl status listener
    • Démarrez le processus d'écoute client :
      [grid@vm ~] srvctl start listener
    • Vérifiez à nouveau le statut du processus d'écoute client sur un noeud. Si le processus d'écoute client est toujours arrêté, recherchez la cause de l'échec :
      1. Utilisez tfactl afin de collecter les journaux de CRS et du système d'exploitation 30 minutes avant et 10 minutes après pour le nom d'hôte hostName indiqué dans le journal. L'heure indiquée dans la charge utile d'événement est toujours au format UTC : pour la collecte par tfactl, ajustez l'heure au fuseau horaire du cluster 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. Consultez le journal du processus 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 de l'événement

Un événement DOWN est créé lorsqu'une instance de base de données est arrêtée. 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 celles de l'utilitaire Server Control (srvctl), ou de toute action de maintenance Oracle Cloud qui utilise ces commandes, telle qu'une mise à jour du logiciel du répertoire de base de base de données. L'événement est de type CRITICAL lorsqu'une instance de base de données est arrêtée de manière inattendue. Un événement DOWN_CLEARED correspondant est créé lorsqu'une instance de base de données est démarrée.

Enoncé 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 des performances si des instances de base de données sont disponibles sur d'autres noeuds du cluster, ou un temps d'inactivité complète 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.

Evénement DOWN de type INFORMATION

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

Evé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 arrêtée.
    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. Recherchez la cause de l'échec de l'instance de base de données.
    1. Consultez les événements Trace File Analyzer (TFA) de la base de données :
      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
    2. Consultez le journal d'alertes de la base de données figurant 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 de l'événement

Une altération 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é à la recherche d'erreurs spécifiques qui indiquent des altérations de bloc physique ou logique, ou des altérations de bloc logique dues à des écritures perdues.

Enoncé du problème

Les altérations peuvent entraîner des erreurs d'application ou de base de données et, dans le pire des cas, des pertes de données importantes si elles ne sont pas traitées rapidement.

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

  • Dans une altération de bloc physique, également appelée altération de support, la base de données ne reconnaît pas le bloc. Le checksum n'est pas valide ou le bloc contient tous les zéros. Exemple d'altération de bloc plus sophistiquée : l'en-tête et le pied de page du bloc ne correspondent pas.
  • Dans le cas d'une altération de bloc logique, le contenu du bloc est physiquement en bon état et les vérifications de bloc physique ne présentent aucune erreur. Cependant, le bloc peut être logiquement incohérent. Exemples d'altération de bloc logique : type de bloc incorrect, numéro de séquence de bloc de journalisation ou de données incorrect, altération d'un élément de ligne ou d'une entrée d'index, ou altérations du dictionnaire de données.

Les altérations de bloc peuvent également être divisées en altérations interblocs et altérations intrabloc :

  • Dans le cas d'une altération intrabloc, l'altération survient dans le bloc lui-même, et peut être une altération de bloc physique ou logique.
  • Dans le cas d'une altération interblocs, l'altération survient entre des blocs et ne peut être qu'une altération de bloc logique.

Oracle recherche 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

Un incident lié à une altération des données survient lorsqu'un composant matériel, logiciel ou réseau entraîne la lecture ou l'écriture de données altérées. L'impact au niveau du service d'un incident lié à une altération des données peut varier, 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 (alors inutilisable). Si aucune action de résolution n'est effectuée rapidement, le temps d'inactivité et la perte de données potentiels peuvent augmenter.

Action/Réparation

La notification de l'événement en cours est actuellement déclenchée en cas d'altérations de bloc physiques (ORA-01578), d'écritures perdues (ORA-00752, ORA-00753 et ORA-00600 avec comme premier argument 3020) et d'altérations logiques (généralement détectées à partir d'ORA-00600 avec comme premier argument kdsgrp1, kdsgrp1, kclchkblk_3, 13013 ou 5463).

Nous vous recommandons de suivre les étapes ci-après :

  1. Vérifiez que ces altérations ont été signalées dans le fichier trace et le fichier alert.log. Créez une demande de service avec le rapport EXAchk le plus récent, l'extrait du fichier alert.log et du fichier trace contenant les erreurs d'altération, l'historique des modifications récentes de l'application, de la base de données ou du logiciel, et les journaux 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 jointe à la demande de service.
  2. Pour plus d'informations sur les recommandations concernant les réparations, reportez-vous à Remarque majeure sur la gestion des problèmes d'altération d'Oracle Database.

Pour les altérations physiques ou les erreurs ORA-1578, consultez les documents suivants :

Remarques :

Vous pouvez utiliser RMAN pour récupérer des blocs de données physiquement altérés. En outre, en utilisant Active Data Guard avec l'application en temps réel, la réparation de bloc automatique des altérations de données physiques est effectuée automatiquement.

Les altérations logiques dues à des écritures perdues (ORA-00752, ORA-00753 et ORA-00600 avec comme premier argument 3020) sur les bases de données principale ou de secours sont détectées sur la base de données principale ou avec le processus Redo Apply de la base de données de secours. Consultez les documents suivants :

Pour les altérations logiques (généralement détectées à partir d'ORA-00600 avec comme arguments kdsgrp1, kclchkblk_3, 13013 ou 5463) :

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Nom d'événement

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Description de l'é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 ne peut pas le faire assez rapidement vers les destinations d'archivage des journaux.

Enoncé du problème

L'instance RAC de base de données Conteneur peut se bloquer temporairement ou définitivement en raison de l'incapacité du journaliseur (LGWR) à écrire les tampons de journalisation dans un fichier de journalisation en ligne. Cela se produit car tous les journaux en ligne doivent être archivés. Une fois que le processus d'archivage (ARC) peut archiver au moins un fichier de journalisation en ligne, LGWR peut reprendre l'écriture des tampons de journalisation dans les fichiers de journalisation en ligne et l'incidence sur l'application est réduite.

Risque

Si l'archiveur ne répond plus temporairement, les applications peuvent subir une brève interruption de service ou un blocage lors de la tentative de validation des modifications de la base de données. Si l'archiveur n'est pas restauré, les processus d'application peuvent subir des retards de traitement prolongés.

Action/Réparation

  • Afin de déterminer la fréquence horaire de chaque thread/instance, reportez-vous à Script To Find Redolog Switch History And Find Archivelog Size For Each Instances In RAC (ID de document 2373477.1).
    • Si un bucket horaire est supérieur à 12, envisagez de redimensionner les fichiers de journalisation en ligne. Reportez-vous au point 2 ci-dessous pour connaître les étapes de redimensionnement.
  • Si la base de données ne répond plus temporairement, l'archiveur risque de ne pas pouvoir suivre le fichier de journalisation généré.
    • Examinez le fichier alert.log, $ORACLE_BASE/diag/rdbms/<nomBdD>/<nomInstance>/trace/alert_<nomInstance>.log, à la recherche de "Tous les journaux en ligne doivent être archivés". Plusieurs événements sur une courte période peuvent indiquer 2 solutions possibles.
      1. Si le nombre de groupes de fichiers de journalisation par thread est inférieur à 4, envisagez d'ajouter des groupes de fichiers de journalisation supplémentaires pour atteindre 4. Reportez-vous au point 1 ci-dessous pour connaître les étapes d'ajout de fichier de journalisation.
      2. L'autre solution possible consiste à redimensionner les fichiers de journalisation. Reportez-vous au point 2 ci-dessous pour connaître les étapes de redimensionnement.
  • Afin d'obtenir des instructions de dimensionnement pour Data Guard ou autre, reportez-vous à Configuration appropriée des fichiers de journalisation en ligne.
  • Ajoutez un groupe de fichiers de journalisation pour chaque thread. La taille du fichier de journalisation supplémentaire doit correspondre à la taille du journal en cours.
    1. Utilisez la requête 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 1 nouveau groupe par thread avec une taille identique à celle des fichiers de journalisation en cours.
      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 en cours plus petits.
    1. Utilisez la requête 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 (number_of_groups_per_thread) pour chaque thread existant. Le paramètre new_redo_size_in_bytes doit être défini selon les instructions dans Configuration appropriée des fichiers de journalisation en ligne. 
      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 d'origine 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, émettez la commande select suivante. 
        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        Supprimez les fichiers de journalisation d'origine plus petits :

        alter database drop logfile <group#>;
  • Si la base de données ne répond plus, les destinations principale et alternative d'archivage des journaux peuvent être pleines.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Nom d'événement

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Description de l'é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.

Enoncé du problème

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

Risque

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

Action/Réparation

Examinez la cause du bloc de session.

  • Consultez les événements TFA de la base de données pour rechercher les modèles de message suivants correspondant à la date/l'heure de l'événement : ORA-32701, "Processus de base de données critique DIA0 bloqué" ou "Processus de base de données critique DIA0 en tant qu'utilisateur root". 
    tfactl events -database <dbName> -instance <instanceName>
  • Consultez 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 ralentir la progression, 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 DIA0 Messages Processus de base de données critique : vérifiez les lignes d'un diagnostic associées indiquant le processus et le motif du blocage

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Nom d'événement

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Description de l'événement

Un événement de type CRITICAL est créé si une sauvegarde de base de données Conteneur avec un statut FAILED est signalée dans la vue v$rman_status.

Enoncé 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 (RPO) et l'objectif de délai de récupération (RTO) peuvent être affectés.

Action/Réparation

Consultez les journaux RMAN correspondant à la date/heure de l'événement. L'horodatage de l'événement (eventTime) est au format UTC. Ajustez-le au besoin pour le 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.
  • Consultez le journal à la recherche d'échecs :
    • Si l'échec est dû à un événement externe en dehors de RMAN, par exemple si l'emplacement de sauvegarde était plein ou en cas de problème de réseau, résolvez le problème externe.
    • Pour les autres erreurs de script RMAN, collectez les journaux de diagnostics 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 est résolu, effectuez une nouvelle sauvegarde incrémentielle. Pour plus d'informations, reportez-vous à Sauvegarde d'une base de données à l'aide de la console.

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

  • Consultez les journaux RMAN pour rechercher la sauvegarde.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Nom d'événement

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Description de l'événement

Un événement de type CRITICAL est créé lorsqu'un groupe de disques ASM atteint une utilisation de l'espace supérieure ou égale à 90 %. Un événement de type INFORMATION est créé lorsque l'utilisation de l'espace par le groupe de disques ASM est inférieure à 90 %.

Enoncé du problème

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

Risque

Un espace insuffisant sur le groupe de disques ASM peut entraîner l'échec de la création d'une base de données, l'échec de la création d'un tablespace et d'un fichier de données, l'échec de l'extension de fichier de données automatique ou l'échec du rééquilibrage ASM.

Action/Réparation

L'espace utilisé sur le groupe de disques ASM est déterminé par l'exécution de la requête suivante lorsque vous êtes connecté à 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é du groupe de disques ASM peut être augmentée des manières suivantes :

  1. Redimensionnez le stockage du cluster de machines virtuelles pour augmenter la capacité du groupe de disques ASM. Pour plus d'informations, reportez-vous à Augmentation du stockage pour un système de base de données de machine virtuelle.

L'utilisation de l'espace du groupe de disques DATA peut être réduite des manières suivantes :

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

L'utilisation de l'espace du groupe de disques RECO peut être réduite des manières suivantes :

  1. Supprimez les points de restauration garantis inutiles. Pour plus d'informations, reportez-vous à Utilisation des 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ées en dehors de la zone de récupération rapide. Pour plus d'informations, reportez-vous à Maintenance de la zone de récupération rapide.