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 :

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 :

Enoncé du problème:

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

Le 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é.

Le 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.

Le 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 des fichiers ensemble, 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.

Le 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.

Le 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.

Le 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 :

Les altérations de bloc peuvent également être divisées en altérations interbloc et altérations intrablocs :

Oracle recherche les erreurs suivantes dans le fichier alert.log :

Le 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 :

Remarque : 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.

Le 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 connaître des délais de traitement prolongés.

Action/Réparation:

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.

Le 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:

Recherchez la cause du bloc de session.

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é.

Le 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 :

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

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 %.

Le 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 à Redimensionnement du système de base de données.

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.