Plusieurs membres redémarrent sur l'hôte hôte principal

Il n'y a aucun problème apparent dans la sortie de la commande db2instance -list et aucune alerte n'est marquée dans la colonne ALERT pour les membres ou les hôtes. Il peut cependant exister un nombre important ou croissant de répertoires FODC, ou l'utilisation de l'espace dans le répertoire de vidage des diagnostics diagpath ($INSTHOME/sqllib/db2dump/ $m par défaut) continue de croître à un rythme anormal (en fonction du comportement historique).

Voici un exemple de sortie de la commande db2instance -list illustrant un environnement à trois membres, à deux fonctions de mise en cache de cluster :
ID        TYPE             STATE           HOME_HOST    CURRENT_HOST  ALERT  PARTITION_NUMBER  LOGICAL_PORT  NETNAME
--        ----             -----           ---------    ------------  -----  ----------------  ------------  -------
0         MEMBER           STARTED         hostA        hostA         NO                    0             0  hostA-ib0
1         MEMBER           STARTED         hostB        hostB         NO                    0             0  hostB-ib0
2         MEMBER           STARTED         hostC        hostC         NO                    0             0  hostC-ib0
128       CF               PRIMARY         hostD        hostD         NO                    -             0  hostD-ib0
129       CF               PEER            hostE        hostE         NO                    -             0  hostE-ib0
	
HOSTNAME       STATE      INSTANCE_STOPPED ALERT
--------       -----      ---------------- -----
hostA          ACTIVE     NO               NO
hostB          ACTIVE     NO               NO
hostC          ACTIVE     NO               NO
hostD          ACTIVE     NO               NO
hostE          ACTIVE     NO               NO
Ce symptôme peut être provoqué par un redémarrage du membre sur l'hôte principal. L'utilisation continue ou répétée de problèmes entraînant plusieurs redémarrages de membres sur l'hôte principal peut entraîner une augmentation de l'utilisation de l'espace du répertoire de vidage des diagnostics diagpath ($INSTHOME/sqllib/db2dump/ $m par défaut)
  • Consultez le journal instance_owner.nfy pour plus d'informations sur le moment où l'incident s'est produit.
  • Recherchez des entrées dans ce fichier journal membre db2diag autour de cet horodatage pour plus de détails sur la raison de l'échec.
    Remarque: recherchez les messages d'erreur liés à db2rstar dans le fichier journal db2diag .
  • Recherchez les répertoires FODC dans l'emplacement diagpath (ou dans le répertoire sqllib/db2dump/ $m par défaut). S'il existe des répertoires FODC, voir le lien connexe vers "Informations sur la capture des données de la première occurrence" pour des instructions sur la procédure à suivre.
  • S'il n'existe pas de répertoire FODC et que la cause de l'erreur est toujours inconnue, consultez le journal des erreurs système de l'hôte concerné.