Récupération des objets endommagés

Reprise sur incident lié au support

Vous pouvez enregistrer des images de support pour des objets afin qu'ils puissent être récupérés s'ils sont endommagés. Cette fonction est disponible uniquement sur les gestionnaires de files d'attente qui utilisent la journalisation linéaire ou la journalisation répliquée et, pour la journalisation linéaire, uniquement pour les objets définis comme récupérables. Vous définissez que les types d'objet sont récupérables à l'aide des attributs de gestionnaire de files d'attente IMGRCOVO et IMGRCOVQ . Voir ALTER QMGR. Si un objet qui n'est pas défini comme récupérable est endommagé, les options de reprise sont les mêmes que pour la journalisation avec réutilisation automatique des journaux.

La reprise sur incident lié au support recrée des objets à partir d'informations enregistrées dans un journal linéaire ou répliqué. Par exemple, si un fichier objet est supprimé par inadvertance ou devient inutilisable pour une autre raison, la reprise sur incident peut le recréer. Les informations du journal requises pour la reprise sur incident lié au support d'un objet sont appelées image de support.

Une image de support est une séquence d'enregistrements de journal contenant une image d'un objet à partir de laquelle l'objet lui-même peut être recréé.

Le premier enregistrement de journal requis pour recréer un objet est appelé enregistrement de reprise sur incident lié au support; il s'agit du début de l'image de support la plus récente pour l'objet. L'enregistrement de reprise sur incident lié au support de chaque objet est l'une des informations enregistrées lors d'un point de contrôle.

Lorsqu'un objet est recréé à partir de son image de support, il est également nécessaire de réexécuter tous les enregistrements de journal décrivant les mises à jour effectuées sur l'objet depuis la dernière image.

Prenons l'exemple d'une file d'attente locale dont l'image de l'objet file d'attente est prise avant qu'un message persistant ne soit inséré dans la file d'attente. Afin de recréer la dernière image de l'objet, il est nécessaire de relire les entrées de journal enregistrant l'insertion du message dans la file d'attente, en plus de relire l'image elle-même.

Les images de support peuvent également être enregistrées manuellement à l'aide de la commande rcdmqimg , décrite dans rcdmqimg. Cette commande écrit une image de support de l'objet IBM MQ .

Le gestionnaire de files d'attente enregistre automatiquement les images de support si IMGSCHED(AUTO) est défini. Pour plus d'informations, voir ALTER QMGR pour plus d'informations sur IMGINTVL et INGLOGLN.

Lorsqu'une image de support a été écrite, seuls les journaux qui contiennent l'image de support, ainsi que tous les journaux créés après cette période, sont requis pour recréer les objets endommagés. L'avantage de la création d'images de support dépend de facteurs tels que la quantité de mémoire disponible et la vitesse à laquelle les fichiers journaux sont créés.

Reprise à partir d'images de support

Un gestionnaire de files d'attente récupère automatiquement certains objets à partir de leur image de support lors du démarrage du gestionnaire de files d'attente. Elle récupère automatiquement une file d'attente si elle était impliquée dans une transaction incomplète lors du dernier arrêt du gestionnaire de files d'attente et qu'elle est endommagée ou endommagée lors du redémarrage.

Vous devez récupérer d'autres objets manuellement à l'aide de la commande rcrmqobj , qui réexécute les enregistrements du journal pour recréer l'objet IBM MQ . L'objet est recréé à partir de sa dernière image trouvée dans le journal, avec tous les événements de journal applicables entre le moment où l'image a été sauvegardée et le moment où la commande de recréation a été émise. Si un objet IBM MQ est endommagé, les seules actions valides pouvant être effectuées sont sa suppression ou sa recréation par cette méthode. Les messages non persistants ne peuvent pas être récupérés de cette manière.

Pour plus d'informations sur la commande rcrmqobj , voir rcrmqobj .

Le fichier journal contenant l'enregistrement de reprise sur incident lié au support, ainsi que tous les fichiers journaux suivants, doivent être disponibles dans le répertoire des fichiers journaux lors de la tentative de reprise sur incident lié au support d'un objet. Si un fichier requis est introuvable, le message d'opérateur AMQ6767 est émis et l'opération de récupération de support échoue. Si vous ne prenez pas d'images de support standard des objets que vous souhaitez recréer, il se peut que l'espace disque soit insuffisant pour contenir tous les fichiers journaux nécessaires à la recréation d'un objet.

Les gestionnaires de file d'attente HA natifs utilisent la journalisation répliquée. Ces gestionnaires de files d'attente tentent la reprise automatique des objets éligibles lorsque des dommages sont détectés. Une fois démarrés, les gestionnaires de files d'attente Native HA, par défaut, tentent automatiquement une reprise asynchrone lorsque des dommages d'objet sont détectés. La reprise peut ne pas être immédiatement possible si, par exemple, l'objet est utilisé par une application ou si les extensions de journal requises pour la reprise sur support ne sont pas disponibles. Dans ces situations, le processus de reprise asynchrone effectue régulièrement des relances. Si le problème qui a empêché la récupération est résolu, l'objet sera récupéré lors de la prochaine tentative, ou l'objet peut être récupéré manuellement à l'aide de la commande rcrmqobj .

Les fichiers d'objet existants

Le gestionnaire de files d'attente stocke les attributs des objets définis dans runmqsc dans des fichiers sur disque. Ces fichiers objet se trouvent dans des sous-répertoires du répertoire de données du gestionnaire de files d'attente.

Par exemple, sur les plateformes AIX® and Linux® , les chaînes sont stockées dans /var/mqm/qmgrs/qmgr/channel.

Les données de ces fichiers objet correspondent à l'image de support des objets. Si ces fichiers objet sont supprimés ou endommagés, l'objet stocké dans ce fichier est endommagé. A l'aide d'un gestionnaire de files d'attente de journalisation linéaire, les objets endommagés peuvent être récupérés à partir du journal à l'aide de la commande rcrmqobj . Les gestionnaires de files d'attente de journalisation répliquée (Native HA) tentent automatiquement de récupérer les objets endommagés lorsqu'ils sont détectés.

Le catalogue et le gestionnaire de files d'attente peuvent être enregistrés, mais ne peuvent pas être récupérés. Si ces objets sont endommagés, le gestionnaire de files d'attente s'arrête de manière préemptive et ces objets sont récupérés automatiquement au redémarrage.

Les abonnements ne sont pas répertoriés dans les objets à enregistrer ou à récupérer, car les abonnements durables sont stockés dans une file d'attente système. Pour enregistrer ou récupérer des abonnements durables, enregistrez ou récupérez SYSTEM.DURABLE.SUBSCRIBER.QUEUE à la place.

Récupération des objets endommagés lors du démarrage

Si le gestionnaire de files d'attente détecte un objet endommagé lors du démarrage, l'action qu'il effectue dépend du type d'objet et de la configuration du gestionnaire de files d'attente pour la prise en charge de la reprise sur incident lié au support.

Si l'objet gestionnaire de files d'attente est endommagé, le gestionnaire de files d'attente ne peut pas démarrer à moins qu'il puisse récupérer l'objet. Si le gestionnaire de files d'attente est configuré avec un journal linéaire et prend donc en charge la reprise sur incident lié au support, IBM MQ tente automatiquement de recréer l'objet gestionnaire de files d'attente à partir de ses images de support. Si la méthode de consignation sélectionnée ne prend pas en charge la reprise sur support, vous pouvez soit restaurer une sauvegarde du gestionnaire de files d'attente, soit supprimer le gestionnaire de files d'attente.

Si des transactions étaient actives lorsque le gestionnaire de files d'attente s'est arrêté, les files d'attente locales contenant les messages persistants non validés insérés ou reçus dans ces transactions sont également nécessaires pour démarrer le gestionnaire de files d'attente. Si l'une de ces files d'attente locales est endommagée et que le gestionnaire de files d'attente prend en charge la reprise sur incident lié au support, il tente automatiquement de les recréer à partir de leurs images de support. Si l'une des files d'attente ne peut pas être récupérée, IBM MQ ne peut pas démarrer.

Si des files d'attente locales endommagées contenant des messages non validés sont détectées lors du démarrage d'un gestionnaire de files d'attente qui ne prend pas en charge la reprise sur support, les files d'attente sont marquées comme objets endommagés et les messages non validés sont ignorés. Cette situation est due au fait qu'il n'est pas possible d'effectuer une reprise sur support des objets endommagés sur un tel gestionnaire de files d'attente et qu'il ne reste plus qu'à les supprimer. Le message AMQ7472 est émis pour signaler tout dommage.

Récupération d'objets endommagés à d'autres moments

La reprise sur support des objets est automatique uniquement lors du démarrage (autre que pour les gestionnaires de files d'attente Native HA, qui utilisent la reprise automatique par défaut). A d'autres moments, lorsque des dommages sont détectés, le message d'opérateur AMQ7472 est émis et la plupart des opérations utilisant l'objet échouent avec le code retour MQRC_OBJECT_DAMAGED. Si l'objet gestionnaire de files d'attente est endommagé à tout moment après le démarrage du gestionnaire de files d'attente, le gestionnaire de files d'attente effectue un arrêt préventif. Lorsqu'un objet a été endommagé, vous pouvez le supprimer ou, si le gestionnaire de files d'attente utilise un journal linéaire, tenter de le récupérer à partir de son image de support à l'aide de la commande rcrmqobj (voir rcrmqobj pour plus de détails).

Si une file d'attente (ou un autre objet) est endommagée, MEDIALOG n'avance pas. En effet, MEDIALOG est le domaine le plus ancien requis pour la reprise sur incident lié au support. Si votre charge de travail continue, CURRLOG continuera d'avancer et de nouvelles extensions seront écrites. Selon votre configuration (y compris votre paramètre LogManagement ), cela peut commencer à remplir votre système de fichiers journaux. Si le système de fichiers journaux se remplit complètement, les transactions sont annulées et le gestionnaire de files d'attente peut s'arrêter brutalement. Par conséquent, lorsqu'une file d'attente est endommagée, il se peut que vous n'ayez qu'un temps d'action limité avant que votre gestionnaire de files d'attente ne s'arrête. Le temps dont vous disposez dépend de la fréquence à laquelle votre charge de travail provoque l'écriture de nouvelles extensions par le gestionnaire de files d'attente et de la quantité d'espace disponible dans votre système de fichiers journaux.

Si vous utilisez la gestion manuelle des journaux, il se peut que vous archiviez des extensions non nécessaires pour la reprise après redémarrage, puis que vous les supprimiez du système de fichiers journaux, même si elles sont encore nécessaires pour la reprise sur support. Cela est acceptable tant que vous pouvez les restaurer à partir de votre archive si nécessaire. Cette règle n'entraîne pas le remplissage de votre système de fichiers journaux lorsqu'une file d'attente est endommagée et que MEDIALOG cesse de progresser. Toutefois, si vous archivez et supprimez uniquement les extensions qui ne sont pas nécessaires pour le redémarrage ou la récupération de support, votre système de fichiers journal commence à se remplir si une file d'attente est endommagée.

Si vous utilisez la gestion automatique ou la gestion des journaux d'archivage, le gestionnaire de files d'attente ne réutilise pas les domaines qui sont encore nécessaires pour la reprise sur incident lié au support, même si vous les avez archivés et que vous avez notifié le gestionnaire de files d'attente à l'aide de la commande SET LOG ARCHIVÉ. Par conséquent, si une file d'attente est endommagée, votre système de fichiers journaux commencera à se remplir.

Si une file d'attente est endommagée, les FFDC OBJECT DAMAGED sont écrits et MEDIALOG s'arrête d'avancer. L'objet endommagé peut être identifié à partir de l'outil de diagnostic de premier niveau (FFDC) ou parce qu'il s'agit de l'objet avec le plus ancien MEDIALOG lorsque vous affichez son statut dans runmqsc.

Si votre système de fichiers journaux est en cours de remplissage et que vous êtes préoccupé par le fait que votre charge de travail est annulée car le système de fichiers journaux est en cours de saturation, la récupération de l'objet ou la mise au repos de votre charge de travail peut arrêter ce processus.

Dans le cas des gestionnaires de file d'attente Native HA, qui utilisent la journalisation répliquée, la récupération automatique des objets endommagés est tentée. Une fois démarrés, les gestionnaires de files d'attente Native HA, par défaut, tentent automatiquement une reprise asynchrone lorsque des dommages d'objet sont détectés. La reprise peut ne pas être immédiatement possible si, par exemple, l'objet est utilisé par une application ou si les extensions de journal requises pour la reprise sur support ne sont pas disponibles. Dans ces situations, le processus de reprise asynchrone effectue régulièrement des relances. Si le problème qui a empêché la récupération est résolu, l'objet sera récupéré lors de la prochaine tentative, ou l'objet peut être récupéré manuellement à l'aide de la commande rcrmqobj .