[z/OS]

Protokolldateien in IBM MQ for z/OS

Protokolldateien enthalten Informationen, die für die Wiederherstellung von Transaktionen erforderlich sind. Aktive Protokolldateien können archiviert werden, sodass die Protokolldaten über einen längeren Zeitraum aufbewahrt werden können.

Was ist eine Protokolldatei?

IBM® MQ zeichnet alle wichtigen Ereignisse auf, wenn sie in einem aktiven Protokollauftreten. Das Protokoll enthält die Informationen, die für eine Wiederherstellung erforderlich sind:
  • Permanente Nachrichten
  • IBM MQ -Objekte, z. B. Warteschlangen
  • IBM MQ -Warteschlangenmanager

Das aktive Protokoll umfasst eine Sammlung von Dateien (bis zu 310), die reihum abwechselnd verwendet werden.

Sie können die Protokollarchivierung aktivieren, damit in einer Archivdatei eine Kopie erstellt wird, wenn das aktive Protokoll voll wird. Mithilfe der Archivierung können Sie Protokolldaten über einen längeren Zeitraum aufbewahren. Wenn Sie die Protokollarchivierung nicht aktivieren, werden die Protokolldateien umlaufend verwendet und frühere Daten darin überschrieben. Zur Wiederherstellung einer Seitengruppe oder von Daten in einer Coupling-Facility-Struktur benötigen Sie die Protokolldaten von dem Zeitpunkt, zu dem die Sicherung der Seitengruppe oder Struktur vorgenommen wurde. Ein Archivprotokoll kann auf einer Festplatte oder einem Bandspeicher erstellt werden.

Archivierung

Da die aktive Protokolldatei eine feste Größe hat, kopiert IBM MQ den Inhalt jeder Protokolldatei in regelmäßigen Abständen in ein Archivprotokoll, bei dem es sich normalerweise um eine Datei auf einer DASD-Einheit oder einem Magnetband handelt. Wenn ein Subsystem-oder Transaktionsfehler auftritt, verwendet IBM MQ das aktive Protokoll und, falls erforderlich, das Archivprotokoll für die Wiederherstellung.

Das Archivprotokoll kann bis zu 1000 sequenzielle Dateien enthalten. Sie können jede Datei mithilfe der z/OS® Integrated Catalog Facility (ICF) katalogisieren.

Die Archivierung ist eine wesentliche Komponente der IBM MQ -Wiederherstellung. Wenn eine Arbeitseinheit mit Wiederherstellung eine lange Laufzeit hat, werden Protokolleinträge dieser Arbeitseinheit möglicherweise auch in das Archivprotokoll geschrieben. In diesem Fall werden zur Wiederherstellung auch Daten aus dem Archivprotokoll benötigt. Wenn die Archivierung jedoch inaktiviert ist, wird das aktive Protokoll umlaufend mit neuen Protokolleinträgen gefüllt, wobei frühere Protokolleinträge überschrieben werden. Dies bedeutet, dass IBM MQ möglicherweise die Arbeitseinheit mit Wiederherstellung nicht zurücksetzen kann und Nachrichten verloren gehen können. In diesem Fall wird der Warteschlangenmanager abnormal beendet.

Deshalb sollten Sie in einer Produktionsumgebung die Archivierung niemals inaktivieren. Falls Sie dies dennoch tun, besteht nach einem System- oder Transaktionsfehler die Gefahr von Datenverlust. Deshalb sollte die Archivierung ausschließlich und allenfalls in einer Testumgebung inaktiviert werden. Verwenden Sie in diesem Fall das Makro CSQ6LOGP , das im Abschnitt CSQ6LOGPbeschrieben wird.

Um Probleme mit ungeplanten Arbeitseinheiten mit langer Laufzeit zu vermeiden, gibt IBM MQ eine Nachricht (CSQJ160I oder CSQJ161I ) aus. wenn während der Auslagerung aktiver Protokolle eine Arbeitseinheit mit langer Laufzeit erkannt wird.

Doppelte Protokollierung

Bei der doppelten Protokollierung wird jeder Protokolleintrag in zwei verschiedene aktive Protokolldateien geschrieben, um die Wahrscheinlichkeit eines Datenverlusts beim Neustart zu minimieren.

Sie können IBM MQ für die Ausführung mit einfacher Protokollierung oder doppelter Protokollierungkonfigurieren. Bei der einfachen Protokollierung werden die Protokolleinträge nur in eine aktive Protokolldatei geschrieben. Jede aktive Protokolldatei ist eine lineare VSAM-Datei (Virtual Storage Access Method) mit einem einzelnen Speicherbereich. Bei der doppelten Protokollierung wird jeder Protokolleintrag in zwei verschiedene Datensätze in der aktiven Protokolldatei geschrieben. Auf diese Weise wird die Wahrscheinlichkeit von Datenverlust beim Neustart minimiert.

Protokollverzögerung

Bei einer Protokollverzögerung (Shunting) werden die Protokolleinträge für einige Arbeitseinheiten weiter unten im Protokoll gespeichert. Dadurch wird die Menge der Protokolldaten verringert, die bei einem Neustart oder einer Auslagerung des Warteschlangenmanagers, für lange laufende oder über lange Zeit unbestätigte Arbeitseinheiten gelesen werden muss.

Wenn eine Arbeitseinheit als lang angesehen wird, wird eine Darstellung jedes Protokollsatzes weiter unten in das Protokoll geschrieben. Dieses Verfahren wird als Verzögerung (Shunting) bezeichnet. Nachdem die gesamte Arbeitseinheit verarbeitet wurde, befindet sie sich in einem verzögerten Zustand. Bei einer Auslagerungs- oder Neustartaktivität, die in Bezug auf die verzögerte Arbeitseinheit ausgeführt wird, können die verzögerten Protokolleinträge anstelle der ursprünglichen Protokolleinträge für die Arbeitseinheit verwendet werden.

Die Erkennung einer lange laufenden Arbeitseinheit ist eine Funktion der Prüfpunktverarbeitung. Zum Zeitpunkt des Prüfpunkts wird jede aktive Arbeitseinheit daraufhin überprüft, ob sie verzögert werden muss oder nicht. Wenn seit dem Erstellen der Arbeitseinheit oder seit ihrer letzten Verzögerung bereits zwei vorherige Prüfpunkte vergangen sind, wird diese Arbeitseinheit verzögert. Dies bedeutet, dass eine Arbeitseinheit auch mehr als einmal verzögert werden kann. Sie wird in diesem Fall als mehrfach verzögerte Arbeitseinheit bezeichnet.

Eine Arbeitseinheit wird alle drei Prüfpunkte verzögert. Allerdings wird der Prüfpunkt asynchron zum Protokollwechsel (oder dem Schreiben des Protokolleintrags, wodurch LOGLOAD überschritten wurde) ausgeführt.

Es findet immer nur ein Prüfpunkt statt, deshalb können möglicherweise mehrere Protokollwechsel stattfinden, bevor ein Prüfpunkt abgeschlossen ist.

Wenn also nicht ausreichend aktive Protokolle vorhanden sind oder falls diese zu klein sind, wird die Verzögerung einer umfangreichen Arbeitseinheit möglicherweise nicht abgeschlossen, bevor alle Protokolle voll sind.

Die Nachricht CSQR027I wird angezeigt, wenn die Verzögerung nicht abgeschlossen werden kann.

Falls die Protokollarchivierung inaktiviert ist, tritt ABEND 5C6 mit Ursachencode 00D1032A auf, wenn versucht wurde, die Arbeitseinheit zurückzusetzen, für die die Verzögerung fehlgeschlagen ist. Verwenden Sie OFFLOAD=YES, um dieses Problem zu vermeiden.

Die Protokollverzögerung (Shunting) ist immer aktiviert und wird unabhängig davon ausgeführt, ob die Protokollarchivierung aktiviert ist oder nicht.

Anmerkung: Obwohl alle Protokollsätze für eine Arbeitseinheit verzögert werden, wird der gesamte Inhalt jedes Datensatzes nicht verzögert, sondern nur der Teil, der für das Zurücksetzen erforderlich ist. Dies bedeutet, dass die Menge der zu speichernden Daten zu klein wie möglich gehalten wird und dass verzögerte Protokolleinträge im Falle eines Seitengruppenfehlers nicht verwendet werden können. Die Laufzeit einer Arbeitseinheit wird als lang eingestuft, wenn die Arbeitseinheit seit mehr als drei Warteschlangenmanager-Prüfpunkten aktiv ist.

Weitere Informationen zur Protokollverzögerung finden Sie unter Protokolle verwalten.

Protokollkomprimierung

Sie können IBM MQ for z/OS so konfigurieren, dass Protokollsätze komprimiert und dekomprimiert werden, wenn sie in die Protokolldatei geschrieben und aus der Protokolldatei gelesen werden.

Mithilfe der Protokollkomprimierung kann die Datenmenge, die in das Protokoll für permanente Nachrichten in privaten Warteschlangen geschrieben werden muss, verringert werden. Der Komprimierungsgrad, der erreicht werden kann, hängt vom Datentyp ab, der in den Nachrichten enthalten ist. Beispielsweise kann die Lauflängencodierung, die auf der Komprimierung wiederholter Instanzen von Bytes basiert, gute Ergebnisse bei strukturierten oder datensatzorientierten Daten liefern.
Achtung: Persistente Nachrichten, die in eine gemeinsam genutzte Warteschlange eingereiht werden, unterliegen nicht der Protokollkomprimierung.

Mithilfe von Feldern im Protokollmanagerabschnitt der Datensätze von System Management Facility 115 (SMF) können Sie den Umfang der erreichten Datenkomprimierung überwachen. Weitere Informationen zu SMF finden Sie unter Systemmanagementfunktion verwenden und Abrechnungs- und Statistikdaten.

Durch die Protokollkomprimierung wird die Prozessorauslastung des Systems erhöht. Die Protokollkomprimierung ist nur dann eine sinnvolle Maßnahme, wenn der Datendurchsatz des Warteschlangenmanagers durch die E/A-Bandbreite bei Schreibvorgängen in den Protokolldateien begrenzt ist oder Einschränkungen bezüglich des Plattenspeicherplatzes bestehen, der zum Speichern der Protokolldateien benötigt wird. Wenn Sie gemeinsam genutzte Warteschlangen verwenden, können Sie Einschränkungen der E/A-Bandbreite mindern, indem Sie der Gruppe mit gemeinsamer Warteschlange weitere Warteschlangenmanager hinzufügen und die Arbeitslast auf mehrere Warteschlangenmanager verteilen.

Die Option für Protokollkomprimierung kann nach Bedarf aktiviert und inaktiviert werden, ohne dass der Warteschlangenmanager gestoppt und neu gestartet werden muss. Der Warteschlangenmanager kann eventuell vorhandene komprimierte Protokolleinträge unabhängig von der aktuellen Protokollkomprimierungseinstellung lesen.

Der Warteschlangenmanager unterstützt 3 Einstellungen für die Protokollkomprimierung.

KEINE
Die Protokolldatenkomprimierung ist inaktiviert. Dies ist der Standardwert.
RLE
Die Protokolldatenkomprimierung wird durch Lauflängencodierung (Run-Length Encoding, RLE) ausgeführt.
ANY
Der Warteschlangenmanager erhält die Möglichkeit, den Komprimierungsalgorithmus auszuwählen, mit dem der höchste Komprimierungsgrad für Protokolleinträge erreicht wird. Diese Option führt zu einer RLE-Komprimierung.
Sie können die Komprimierung von Protokolleinträgen auf folgende Weisen steuern:
  • Die Befehle SET und DISPLAY LOG in MQSC; siehe SET LOG und DISPLAY LOG
  • Die Funktionen "Set Log" und "Inquire Log" in der PCF-Schnittstelle; siehe Set log und Inquire log
  • Makro CSQ6LOGP im Systemparametermodul; siehe CSQ6LOGP

Darüber hinaus unterstützt das Druckdienstprogramm für Protokolle, 'CSQ1LOGP', das Aufheben der Komprimierung von komprimierten Protokolleinträgen.

Protokolldaten

Das Protokoll kann bis zu 18 Trillionen (1,8*1019) Byte enthalten. Jedes Byte kann durch seinen Abstand zum Beginn des Protokolls adressiert werden. Diese Art der Adressierung wird als relative Byteadresse (Relative Byte Address, RBA) bezeichnet.

Die relative Byteadresse wird mithilfe eines 6-Byte- oder 8-Byte-Feldes angegeben, sodass der adressierbare Gesamtbereich 248 bzw. 264 Byte beträgt, je nachdem, ob Protokoll-RBAs mit sechs oder mit acht Byte verwendet werden.

Wenn IBM MQ jedoch feststellt, dass der verwendete Bereich über F00000000000 (bei Verwendung von 6-Byte-RBAs) oder FFFF800000000000 (bei Verwendung von 8-Byte-Protokoll-RBAs) liegt, werden Nachrichten CSQI045, CSQI046, CSQI047und CSQJ032 ausgegeben und Sie werden gewarnt, das Protokoll RBA zurückzusetzen.

Wenn der RBA-Wert den Wert FFF800000000 erreicht (wenn Protokoll-RBAs mit 6 Byte verwendet werden) oder FFFFFFC000000000 (wenn Protokoll-RBAs mit 8 Byte verwendet werden), wird der Warteschlangenmanager mit dem Ursachencode 00D10257beendet.

Nachdem die Warnungen bezüglich des belegten Protokollbereichs ausgegeben wurden, sollten Sie eine Betriebsunterbrechung des Warteschlangenmanagers planen, in der der Warteschlangenmanager für die Verwendung von Protokoll-RBAs konvertiert oder das Protokoll zurückgesetzt werden kann. Die Prozedur zum Zurücksetzen des Protokolls ist im Abschnitt Protokoll des Warteschlangenmanagers zurücksetzendokumentiert.

Wenn Ihr Warteschlangenmanager Protokoll-RBAs mit 6 Byte verwendet, sollten Sie den Warteschlangenmanager so konvertieren, dass er Protokoll-RBAs mit 8 Byte verwendet, anstatt das Protokoll des Warteschlangenmanagers zurückzusetzen, wie im Abschnitt Größere relative Byteadresse für das Protokoll implementierenbeschrieben.

Das Protokoll besteht aus Protokolleinträgen, die jeweils einen Satz an Protokolldaten darstellen, die wie eine individuelle Einheit behandelt werden. Ein Protokolleintrag wird entweder durch die relative Byteadresse des ersten Byte seines Headers identifiziert oder durch seine Protokollsatzfolgenummer (Log Record Sequence Number, LRSN). Mit einer relativen Byteadresse oder Protokollsatzfolgenummer wird ein bestimmter Eintrag angegeben, der an einem bestimmten Punkt im Protokoll beginnt.

Ob zur Bezeichnung des Protokollpunkts die relative Byteadresse oder Protokollsatzfolgenummer erforderlich ist, hängt davon ab, ob Sie Gruppen mit gemeinsamer Warteschlange verwenden oder nicht. In einer Umgebung mit gemeinsam genutzten Warteschlangen kann die relative Byteadresse nicht zur eindeutigen Identifizierung eines Protokollpunkts verwendet werden, weil dieselbe Warteschlange gleichzeitig von mehreren Warteschlangenmanagern aktualisiert werden kann und jeder Warteschlangenmanager sein eigenes Protokoll hat. Um dieses Problem zu lösen, wird die Protokollsatzfolgenummer aus einem Zeitmarkenwert abgeleitet, die nicht unbedingt die physische Verschiebung des Protokolleintrags innerhalb des Protokolls darstellt.

Jeder Protokollsatz hat einen Header, der seinen Typ, die IBM MQ -Unterkomponente, die den Datensatz erstellt hat, und für Datensätze der Arbeitseinheit mit Wiederherstellung eine ID der Arbeitseinheit mit Wiederherstellung angibt.

Es gibt vier Protokolleintragstypen, die in den folgenden Abschnitten beschrieben sind:

Protokolleinträge für Arbeitseinheiten mit Wiederherstellung

Die meisten Protokollsätze beschreiben Änderungen an IBM MQ -Warteschlangen. All solche Änderungen werden mithilfe von Arbeitseinheiten mit Wiederherstellung ausgeführt.

IBM MQ verwendet spezielle Protokollierungsverfahren mit undo/redo und kompensierenden Protokollsätzen , um die Neustartzeiten zu reduzieren und die Systemverfügbarkeit zu verbessern.

Dies führt unter anderem dazu, dass die Neustartdauer gebunden ist. Wenn während des Neustarts ein Fehler auftritt, sodass der Warteschlangenmanager ein zweites Mal neu gestartet werden muss, muss keine der Wiederherstellungsaktivitäten, die bis zum Fehler beim ersten Neustart abgeschlossen wurden, beim zweiten Neustart erneut angewendet werden. Dies bedeutet, dass nachfolgende Neustarts nicht immer länger dauern, bis sie abgeschlossen sind.

Prüfpunktsätze

Um die Neustartzeit zu reduzieren, verwendet IBM MQ im normalen Betrieb regelmäßige Prüfpunkte. Diese Prüfpunkte treten zu folgenden Zeitpunkten auf:
  • Wenn eine vordefinierte Anzahl von Protokolleinträgen geschrieben wurde. Diese Zahl wird durch den Prüfpunktfrequenzoperanden LOGLOAD des Systemparametermakros CSQ6SYSPdefiniert, das im Abschnitt CSQ6SYSPbeschrieben wird.
  • Am Ende eines erfolgreichen Neustarts.
  • Bei normaler Beendigung.
  • Wenn IBM MQ zur nächsten aktiven Protokolldatei im Zyklus wechselt.

Zu dem Zeitpunkt, zu dem ein Prüfpunkt gesetzt wird, gibt IBM MQ den Befehl DISPLAY CONN aus (beschrieben in DISPLAY CONN ) Intern, sodass eine Liste der derzeit unbestätigten Verbindungen in das z/OS -Konsolenprotokoll geschrieben wird.

Seitengruppensteuersätze

Diese Datensätze registrieren die Seitengruppen und Pufferpools, die dem IBM MQ -Warteschlangenmanager an jedem Prüfpunkt bekannt sind, und zeichnen Informationen zu den Protokollbereichen auf, die für die Datenträgerwiederherstellung der Seitengruppe zum Zeitpunkt des Prüfpunkts erforderlich sind.

Bestimmte dynamische Änderungen an Seitengruppen und Pufferpools werden ebenfalls als Seitengruppensteuersätze erstellt, damit die Änderungen zurückgeschrieben und beim nächsten Neustart des Warteschlangenmanagers automatisch wiederhergestellt werden können.

CF-Struktursicherungssätze

Diese Protokolleinträge enthalten Daten, die als Reaktion auf den Befehl BACKUP CFSTRUCT aus einer Coupling-Facility-Listenstruktur gelesen werden. Im unwahrscheinlichen Fall eines Fehlers in Zusammenhang mit der Coupling-Facility-Struktur werden diese Protokolleinträge zusammen mit den Protokolleinträgen für eine Arbeitseinheit mit Wiederherstellung durch den Befehl RECOVER CFSTRUCT dazu verwendet, die Datenträgerwiederherstellung der Coupling-Facility-Struktur bis zum Fehlerpunkt durchzuführen.