AS/400 Journaling: Unterschied zwischen den Versionen

Aus Knowledgebase
Zur Navigation springen Zur Suche springen
(+Weblinks)
 
(Überarbeitet, Remote-Journals eingearbeitet)
 
Zeile 5: Zeile 5:
* '''der Journalempfänger''' wird mit dem Journal verknüpft und dient als Container für die Aufzeichnungen.
* '''der Journalempfänger''' wird mit dem Journal verknüpft und dient als Container für die Aufzeichnungen.


Journalling ermöglicht z. B. die punktgenaue Wiederherstellung einer Datenbankdatei, nachdem diese von einer Sicherung zurückgespeichert werden musste. Ebenso ist es möglich, einen älteren Stand einer Datenbankdatei wieder herzustellen. Beides wird mit dem Befehl WRKJRN und den zugehörigen Optionen erreicht.
Journalling ermöglicht z. B.
 
* die punktgenaue Wiederherstellung einer Datenbankdatei, nachdem diese von einer Sicherung zurückgespeichert werden musste. Ebenso ist es möglich, einen älteren Stand einer Datenbankdatei wieder herzustellen. Beides wird mit dem Befehl WRKJRN und den zugehörigen Optionen erreicht.
Ein ebenfalls wichtiger Punkt: Das Betriebssystem kann mit Hilfe von Journaling geöffnete Datenbankdateien in konsistentem Zustand sichern.
* geöffnete Datenbankdateien in konsistentem Zustand zu sichern.
* schreibende Datenbankoperationen zu bündeln und entweder alle anzuwenden, oder keine: Transaktionen.<ref>Dazu sind allerdings noch Anpassungen im Programmcode notwendig.</ref>


== Journaling einrichten ==
== Journaling einrichten ==
Zeile 13: Zeile 14:


=== CRTJRNRCV ===
=== CRTJRNRCV ===
Zuerst muss ein (leerer) Journalempfänger eingerichtet werden. Bei der Einrichtung empfiehlt es sich, eine Empfängerschwelle einzurichten. Das ist die Angabe der maximalen Größe in Kibibytes. Als Name ist es vorteilhaft, den Namen selbst mit nachfolgenden Ziffern bis zur maximalen Länge aufzufüllen. Z.&thinsp;B. ''myrcv00001''.
Zuerst muss ein (leerer) Journalempfänger eingerichtet werden. Bei der Einrichtung empfiehlt es sich, eine Empfängerschwelle einzurichten. Das ist die Angabe der maximalen Größe in KiB. Als Name ist es vorteilhaft, den Namen selbst mit nachfolgenden Ziffern bis zur maximalen Länge aufzufüllen. Z.&thinsp;B. ''myrcv00001''.


=== CRTJRN ===
=== CRTJRN ===
Danach wird das Journal selbst erzeugt und im gleichen Schritt mit dem ersten Empfänger verknüpft. Wenn die Empfängerverwaltung auf ''*system'' umgestellt wird, nimmt einem das OS das regelmäßige Putzen ab: Wenn der oben genannte Schwellwert überschritten wurde, wird automatisch ein neuer Empfänger mit einer um eins höheren fortlaufenden Nummer erzeugt und angehängt. Der Schwellwertparameter wird vom bestehenden Empfänger übernommen.<br />
Danach wird das Journal selbst erzeugt und im gleichen Schritt mit dem eben angelegten Empfänger verknüpft. Wenn die Empfängerverwaltung auf ''*SYSTEM'' umgestellt wird, nimmt einem das OS das regelmäßige Putzen ab: Wenn der oben genannte Schwellwert überschritten wurde, wird automatisch ein neuer Empfänger mit einer um eins höheren fortlaufenden Nummer erzeugt und angehängt. Der Schwellwertparameter wird vom bestehenden Empfänger übernommen.<br />
Ebenso ist es möglich, alte Empfänger automatisch löschen zu lassen. Als Voraussetzung müssen diese gesichert worden sein (SAVLIB o.&thinsp;Ä.). Ob das sinnvoll ist, ist individuell von der eigenen Sicherungsstrategie abhängig.<br />
Ebenso ist es möglich, alte Empfänger automatisch löschen zu lassen. Als Voraussetzung müssen diese gesichert worden sein (SAVLIB o.&thinsp;Ä.). Ob das sinnvoll ist, ist individuell von der eigenen Sicherungsstrategie abhängig.<br />
Um Platz zu sparen kann der Parameter RCVSIZOPT(*RMVINTENT) benutzt werden. Angehängte Journalempfänger werden dann von internen Einträgen befreit, die nur für eine Wiederherstellung im Rahmen eines IPLs benötigt werden.
Um Platz zu sparen kann der Parameter RCVSIZOPT(*RMVINTENT) benutzt werden. Angehängte Journalempfänger werden dann von internen Einträgen befreit, die nur für eine Wiederherstellung im Rahmen eines abnormalen IPLs benötigt werden.


=== STRJRNPF ===
=== STRJRNPF ===
Zeile 34: Zeile 35:


Die beiden letzten Punkte können auch einfacher durch die Ansicht in ''WRKLIB'', Option 12 erreicht werden.
Die beiden letzten Punkte können auch einfacher durch die Ansicht in ''WRKLIB'', Option 12 erreicht werden.
== Ferne Journale ==
Ein ''Fernes Journal'' ist nichts weiter als die automatische Replikation von Journals auf eine weitere AS/400.<br />
Diese Journaldateien können einfach nur gelagert werden, um im Falle eines Falles darauf zugreifen zu können; oder diese können benutzt werden, um eine dort befindliche Kopie der Datenbank auf dem jeweils aktuellen Stand zu halten.
Im Folgenden gilt:
* Die ''Quell''maschine ist die primäre AS/400, auf der die Produktivdatenbank liegt,
* die ''Ziel''maschine ist das Backupsystem.
=== Vorarbeiten ===
Quell- und Zielmaschine müssen miteinander kommunizieren können. Das Mittel der Wahl für V4R5 ist Remote-Journaling via SNA.
Die Quellmaschine muss einen Eintrag für die Zielmaschine in ihrem Verzeichnis der bekannten ''relationalen Datenbanken'' erhalten. Dies kann mit ''WRKRDBDIRE'' vorgenommen werden.<br />
Falls noch kein Eintrag für die Quellmaschine (Typ *LOCAL) vorhanden ist, muss dieser ebenfalls hinzugefügt werden.
Auf der Zielmaschine wird sinnvollerweise ein Benutzer samt Library eingerichtet, mit dem sich die Quellmaschine auf die Zielmaschine verbinden darf (CRTLIB, CRTUSRPRF, CHGOBJOWN).
Der eingerichtete Benutzer muss nun auf der hinterlegt werden (ADDSVRAUTE). Dabei ist als lokales Benutzerprofil dasjenige zu hinterlegen, mit dem später die eigentliche Journalverbindung eingerichtet wird.
* Auf der Quellmaschine:
ADDRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) RMTRCVLIB(MYLIB) RMTJRNTYPE(*TYPE2)
CHGRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) JRNSTATE(*ACTIVE)
Bereits vorhandene Einträge werden nun übertragen.
* Rückbau:
RMVRMTJRN RDB(RMTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN)


== Weblinks ==
== Weblinks ==
Zeile 39: Zeile 67:
* [https://docs.starquest.com/Products/sqdrplus/SQDRManager.hlp/Configuring_Remote_Journaling_on_the_DB2_for_i_Source.htm Configuring Remote Journaling on the DB2 for i Source]
* [https://docs.starquest.com/Products/sqdrplus/SQDRManager.hlp/Configuring_Remote_Journaling_on_the_DB2_for_i_Source.htm Configuring Remote Journaling on the DB2 for i Source]
* [http://search400.techtarget.com/tip/Tips-for-using-Remote-Journal Tips for using Remote Journal]
* [http://search400.techtarget.com/tip/Tips-for-using-Remote-Journal Tips for using Remote Journal]
== Fußnoten ==
<references />


[[Kategorie:AS/400]]
[[Kategorie:AS/400]]
[[Kategorie:Datenbank]]
[[Kategorie:Datenbank]]

Aktuelle Version vom 30. Dezember 2021, 11:31 Uhr

Die AS/400-Plattform beinhaltet die Möglichkeit, Änderungen an Datenbankdateien aufzuzeichnen. Dies wird dort als Journaling bezeichnet.

Die Implementation greift auf zwei Objektarten der AS/400 zurück:

  • Das Journal wird mit den zu überwachenden Datenbankdateien verknüpft und extrahiert die gewünschten Änderungen,
  • der Journalempfänger wird mit dem Journal verknüpft und dient als Container für die Aufzeichnungen.

Journalling ermöglicht z. B.

  • die punktgenaue Wiederherstellung einer Datenbankdatei, nachdem diese von einer Sicherung zurückgespeichert werden musste. Ebenso ist es möglich, einen älteren Stand einer Datenbankdatei wieder herzustellen. Beides wird mit dem Befehl WRKJRN und den zugehörigen Optionen erreicht.
  • geöffnete Datenbankdateien in konsistentem Zustand zu sichern.
  • schreibende Datenbankoperationen zu bündeln und entweder alle anzuwenden, oder keine: Transaktionen.[1]

Journaling einrichten

Mit der Taste F4 kann wie gehabt die Formulardarstellung als Ausfüllhilfe für die einzelnen Parameter aufgerufen werden.

CRTJRNRCV

Zuerst muss ein (leerer) Journalempfänger eingerichtet werden. Bei der Einrichtung empfiehlt es sich, eine Empfängerschwelle einzurichten. Das ist die Angabe der maximalen Größe in KiB. Als Name ist es vorteilhaft, den Namen selbst mit nachfolgenden Ziffern bis zur maximalen Länge aufzufüllen. Z. B. myrcv00001.

CRTJRN

Danach wird das Journal selbst erzeugt und im gleichen Schritt mit dem eben angelegten Empfänger verknüpft. Wenn die Empfängerverwaltung auf *SYSTEM umgestellt wird, nimmt einem das OS das regelmäßige Putzen ab: Wenn der oben genannte Schwellwert überschritten wurde, wird automatisch ein neuer Empfänger mit einer um eins höheren fortlaufenden Nummer erzeugt und angehängt. Der Schwellwertparameter wird vom bestehenden Empfänger übernommen.
Ebenso ist es möglich, alte Empfänger automatisch löschen zu lassen. Als Voraussetzung müssen diese gesichert worden sein (SAVLIB o. Ä.). Ob das sinnvoll ist, ist individuell von der eigenen Sicherungsstrategie abhängig.
Um Platz zu sparen kann der Parameter RCVSIZOPT(*RMVINTENT) benutzt werden. Angehängte Journalempfänger werden dann von internen Einträgen befreit, die nur für eine Wiederherstellung im Rahmen eines abnormalen IPLs benötigt werden.

STRJRNPF

Nun müssen noch die gewünschten Datenbankdateien mit dem Journal verknüpft werden. Bei dieser Verknüpfung kann angegeben werden, welche Daten erfasst werden. Im Regelfall kann auf Journaleinträge verzichtet werden, die nun Öffnen und Schließen der Datei anzeigen. Umgekehrt kann es sinnvoll sein, das Vorherige und nachfolgende Abbild eines Datensatzes aufzuzeichnen. Ein Fehler ist so ohne globalen Eingriff (mit der verbundenen jetzt-niemand-an-der-DB-fummeln) durch Journalrollbacks schnell korrigiert (DSPJRN).

Journaling von Zugriffspfaden

Zugriffspfade sind in der herkömmlichen Datenbankwelt als Index bekannt.
Die Aufzeichnung von Zugriffspfaden via STRNJRNAP ermöglicht dem Betriebssystem nach einem Stromausfall o. Ä. die schnellere Wiederherstellung eines konsistenten Zustandes. Dieses Feature scheint daher vor allem bei großen DB-Dateien sinnvoll, während die Zeitersparnis bei wenigen Megabytes großen Datenbanken eher gering sein dürfte.

Journaling rückbauen

Der Rückbau von Journaling findet in umgekehrter Reihenfolge statt:

  • Verknüpfung mit Datenbankdateien lösen (ENDJRNPF, ggfs. vorher ENDJRNAP),
  • Journal löschen (DLTJRN),
  • Journalempfänger löschen (DLTJRNRCV).

Die beiden letzten Punkte können auch einfacher durch die Ansicht in WRKLIB, Option 12 erreicht werden.

Ferne Journale

Ein Fernes Journal ist nichts weiter als die automatische Replikation von Journals auf eine weitere AS/400.
Diese Journaldateien können einfach nur gelagert werden, um im Falle eines Falles darauf zugreifen zu können; oder diese können benutzt werden, um eine dort befindliche Kopie der Datenbank auf dem jeweils aktuellen Stand zu halten.

Im Folgenden gilt:

  • Die Quellmaschine ist die primäre AS/400, auf der die Produktivdatenbank liegt,
  • die Zielmaschine ist das Backupsystem.

Vorarbeiten

Quell- und Zielmaschine müssen miteinander kommunizieren können. Das Mittel der Wahl für V4R5 ist Remote-Journaling via SNA.

Die Quellmaschine muss einen Eintrag für die Zielmaschine in ihrem Verzeichnis der bekannten relationalen Datenbanken erhalten. Dies kann mit WRKRDBDIRE vorgenommen werden.
Falls noch kein Eintrag für die Quellmaschine (Typ *LOCAL) vorhanden ist, muss dieser ebenfalls hinzugefügt werden.

Auf der Zielmaschine wird sinnvollerweise ein Benutzer samt Library eingerichtet, mit dem sich die Quellmaschine auf die Zielmaschine verbinden darf (CRTLIB, CRTUSRPRF, CHGOBJOWN).

Der eingerichtete Benutzer muss nun auf der hinterlegt werden (ADDSVRAUTE). Dabei ist als lokales Benutzerprofil dasjenige zu hinterlegen, mit dem später die eigentliche Journalverbindung eingerichtet wird.

  • Auf der Quellmaschine:
ADDRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) RMTRCVLIB(MYLIB) RMTJRNTYPE(*TYPE2)
CHGRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) JRNSTATE(*ACTIVE)

Bereits vorhandene Einträge werden nun übertragen.

  • Rückbau:
RMVRMTJRN RDB(RMTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN)

Weblinks

Fußnoten

  1. Dazu sind allerdings noch Anpassungen im Programmcode notwendig.