![[IBM i]](ngibmi.gif)
Journalverwendung des Warteschlangenmanagers unter IBM i
In diesen Informationen wird erläutert, wie IBM® MQ for IBM i Journale in seiner Operation verwendet, um Aktualisierungen lokaler Objekte zu steuern.
Persistente Aktualisierungen von Nachrichtenwarteschlangen werden in zwei Phasen durchgeführt. Die Datensätze, die die Aktualisierung darstellen, werden zuerst in das Journal geschrieben, und anschließend wird die Warteschlangendatei aktualisiert.
Die Journalempfänger können daher mehr auf dem neuesten Stand als die Warteschlangendateien sein. Um sicherzustellen, dass die Neustartverarbeitung an einem konsistenten Punkt beginnt, verwendet IBM MQ Prüfpunkte.
Ein Prüfpunkt ist ein Zeitpunkt, an dem der in dem Journal beschriebene Datensatz mit dem Datensatz in der Warteschlange identisch ist. Der Prüfpunkt selbst besteht aus der Reihe der Journalsätze, die zum erneuten Starten des Warteschlangenmanagers erforderlich sind. Der Status aller Transaktionen (d.h. Arbeitseinheiten), die zum Zeitpunkt des Prüfpunkts aktiv sind, ist beispielsweise der Status aller Transaktionen.
Prüfpunkte werden automatisch von IBM MQgeneriert. Sie werden beim Starten und Herunterfahren des Warteschlangenmanagers und nach der Protokollierung einer bestimmten Anzahl von Operationen ausgeführt.
RCDMQMIMG OBJ(*ALL) OBJTYPE(*ALL) MQMNAME(Q_MGR_NAME) DSPJRNDTA(*YES)
Wenn die Warteschlangen weitere Nachrichten verarbeiten, wird der Prüfpunktsatz mit dem aktuellen Status der Warteschlangen nicht konsistent.
Wenn IBM MQ erneut gestartet wird, sucht es den letzten Prüfpunktsatz im Protokoll. Diese Informationen werden in der Prüfpunktdatei gehalten, die am Ende jedes Prüfpunkts aktualisiert wird. Der Prüfpunktsatz stellt den letzten Konsistenzpunkt zwischen dem Protokoll und den Daten dar. Die Daten von diesem Prüfpunkt werden verwendet, um die Warteschlangen so wiederherzustellen, wie sie an der Prüfpunktzeit vorhanden waren. Wenn die Warteschlangen erneut erstellt werden, wird das Protokoll dann vorgespielt, um die Warteschlangen wieder in den Zustand zu bringen, in dem sie sich vor Systemausfall oder in der Nähe befanden.
TESTQ im Warteschlangenmanager TEST. Dies wird durch die IFS-Datei dargestellt:/QIBM/UserData/mqm/qmgrs/TEST/queues

- A
- Die IFS-Dateidarstellung der Warteschlange ist mit den im Journal enthaltenen Informationen konsistent.
- B
- Ein Journaleintrag wird in das Journal geschrieben, in dem eine
Put-Operation in der Warteschlange definiert wird. - C
- Die entsprechende Aktualisierung wird in die Warteschlange gestellt.
- D
- Ein Journaleintrag wird in das Journal geschrieben, in dem eine
Get-Operation aus der Warteschlange definiert wird. - E
- Die entsprechende Aktualisierung wird in die Warteschlange gestellt.
Der Schlüssel zu den Wiederherstellungsfunktionen von IBM MQ for IBM i ist, dass der Benutzer die IFS-Dateidarstellung von TESTQ als Zeit Aspeichern und anschließend die IFS-Dateidarstellung von TESTQ als Zeit Ewiederherstellen kann, indem er das gespeicherte Objekt zurückspeichert und die Einträge im Journal ab Zeit A wiedergibt.
Diese Strategie wird von IBM MQ for IBM i verwendet, um persistente Nachrichten nach einem Systemausfall wiederherzustellen. IBM MQ speichert einen bestimmten Eintrag in den Journalempfängern und stellt sicher, dass die Einträge in den Journalen ab diesem Zeitpunkt beim Start wiedergegeben werden. Dieser Starteintrag wird in regelmäßigen Abständen neu berechnet, sodass IBM MQ nur die minimal erforderliche Wiedergabe beim nächsten Start ausführen muss.
IBM MQ bietet eine individuelle Wiederherstellung von Objekten. Alle persistenten Informationen zu einem Objekt werden in den lokalen IBM MQ for IBM i -Journalen aufgezeichnet. Jedes beschädigte oder beschädigte IBM MQ -Objekt kann vollständig aus den im Journal gespeicherten Informationen wiederhergestellt werden.
Weitere Informationen zur Verwaltung von Empfängern durch das System finden Sie unter Verfügbarkeit, Backup, Wiederherstellung und Neustart aufIBM i .