Journaling von LF Objekt

[dbausnnd]

Hallo,

das journlisieren von Logischen macht das überhaupt Sinn? Wenn die PF auch journalisiert wird ist das dann nicht doppelgemoppelt???

Danke schon mal für die Hilfe

dbausnnd

[BenderD]

... die Journale von STRJRNAP werden nur intern zur Wiederherstellung genutzt und nach meiner Erfahrung braucht man das bei heutiger CPU Leistung eher nicht.

D*B

Hallo,

das journlisieren von Logischen macht das überhaupt Sinn? Wenn die PF auch journalisiert wird ist das dann nicht doppelgemoppelt???

Danke schon mal für die Hilfe

dbausnnd

[dbausnnd]

Verstehe ich das richtig? LF Objekte werden lediglich als Zugriffspfad journalisiert?

[Pikachu]

Umgekehrt wird eher ein Schuh draus: Zugriffspfade werden journalisiert - unabhängig davon ob sie einer PF oder LF gehören.

[Fuerchau]

Bei einer LF kann man nicht viele Journaleinträge bekommen (Open/Close), da die Daten über die PF journalisiert werden.
Beim Wiederherstellen über Journale werden die LF's ja zwangsläufig über die PF mit aufgebaut.

Eine Journalisierung für LF's macht nur Sinn, wenn man über die Open/Close-Einträge mitbekommen bzw. auswerten will, wer wann welche LF verwendet hat.
Bei SQL also vollkommen sinnlos.

[dbausnnd]

Vielen Dank. Das ist die Antwort die ich brauche

[Pikachu]

Wahrscheinlich ist der Befehl STRJRNAP (Aufzeichnen des Zugriffspfads starten) für pysische und logische Dateien gemeint. Was macht der eigentlich genau?

[Fuerchau]

In die PF wird das Journal und die Art der Aufzeichnung eingetragen (DSPFD).

[Pikachu]

Der STRJRNPF für physische Dateien ist mir klar. Aber was macht der STRJRNAP?

[Fuerchau]

Drück doch mal bei dem Kommando einfach F1->F2.

[Christian Bartels]

Vielleicht sollte man in diesem Zusammenhang auch noch SMAPP (= System Managed Access Path Protection) erwähnen. Beim expliziten Aufzeichnen von Zugriffspfaden(Indizes) geht es darum, den Wiederanlauf nach einem abnormalen Systemende ("Crash") zu beschleunigen.

Grundsätzlich sind nach einem abnormalen Systemende erstmal alle Zugriffspfade in zweifelhaftem Zustand, die über physischen Dateien liegen, die zum Crash-Zeitpunkt offen waren. Es könnte ja sein, daß kurz vor dem Crash eine Datenänderung erfolgt ist, die den Zugriffspfad betroffen hat, ohne daß der Zugriffspfad noch angepaßt werden konnte. Sofern der Zugriffspfad nicht in ein Journal aufgezeichnet wird, kann das System ihn beim Hochfahren nur löschen und komplett neu aufbauen, damit sichergestellt ist, daß Zugriffspfad und physische Datei synchronisiert sind. Man kann die Zugriffspfade mit STRJRNAP explizit ins Journal aufzeichnen, und dann geht die Wiederherstellung für diesen Zugriffspfad sehr schnell. Weil das aber die wenigsten gemacht haben, mußten früher nach einem abnormalen Systemende sehr viele (und z.T. sehr große) Zugriffspfade wiederhergestellt werden, und das hat sehr lange IPL-Zeiten nach einem Crash verursacht.

Mit V3R1M0 wurde deshalb SMAPP eingeführt. Mit dem Befehl EDTRCYAP kann man eine Zeit vorgeben, die das System maximal zur Wiederherstellung von Zugriffspfaden verwenden soll. Intern entscheidet das System dann selbständig, für welche Zugriffpfade die (interne) Journalaufzeichnung automatisch gestartet wird, damit die Vorgabezeit eingehalten werden kann. Anfangs war die Vorgabezeit übrigens 150 Minuten, inzwischen liegt sie bei 50 Minuten. Der Hilfetext von EDTRCYAP hat weitere Informationen zu dem Thema.

Fazit ist also, daß man STRJRNAP eigentlich gar nicht mehr braucht, weil SMAPP einem die Arbeit automatisch abnimmt.

Mit freundlichen Grüßen,
Christian Bartels.