Journalempfänger sichern

[bie-dro]

Hallo Spezialisten!

Vor Kurzem haben wir angefangen unsere DDS-erzeugten Dateien durch SQL-Tabellen zu ersetzen. Die neuen Tabellen kommen in ein eigens dafür erstelltes Schema und werden automatisch journalisiert.

Beim Sichern des Journalempfängers erhalten wir folgende Meldung:


CPF7080 Information 00 21.01.08 23:47:07,195312 QJOSAVRC QSYS 021B QSRSVPST QSYS 01A1
Nachricht . . . : Empfänger QSQJRN0005 in TESTPL_SCM gesichert, während er
zugeordnet war.
Ursache . . . . : Der Journalempfänger QSQJRN0005 in Bibliothek TESTPL_SCM
wurde gesichert, während er dem Journal zugeordnet war. Diese
Sicherungskopie des Journalempfängers QSQJRN0005 ist nicht vollständig, da
die Journaleinträge nach der Sicherung weiterhin in den Empfänger gestellt
werden. Um eine vollständige Version des Journalempfängers QSQJRN0005
zurückzuspeichern, muss er erneut gesichert werden, nachdem die Zuordnung
zum Journal freigegeben wurde. Technische Beschreibung . . . . . . . :
Wurde der Empfänger während der Sicherung abgehängt, konnte das System
möglicherweise keine vollständige Sicherungskopie erstellen. Den Empfänger
erneut sichern, um eine vollständige Sicherungskopie zu erhalten. Was bedeutet diese Meldung? Wurde der Journalempfänger denn nun gesichert, oder nicht? Wieso hängt das System den Journalempfänger nicht selbständig ab, bevor es den Journalempfänger sichert?

Wir haben das Journal so eingestellt, dass das System die Journalempfänger selber verwalten soll und nicht mehr benötigte Empfänger eigenständig löscht.

Nach der Sicherung wurde der Journalempfänger QSQJRN0005 vom System automatisch gelöscht und der aktuelle Empfänger lautet nun QSQJRN0006.

Müssen wir noch etwas bei der Journalisierung beachten?

Schönen Gruß
Artur Janzen

[Fuerchau]

An einem Journal hängt grundsätzlich auch ein Empfänger.
Die Sicherung sichert das Objekt, allerdings können offene Commit's natürlich nicht gesichert werden.

Ein Journal wird normalerweise bei der automatischen Verwaltung erst gelöscht, wenn es gesichert ist.

Ein offener Commit kann nicht über 2 Empfänger gehen (Inconsistenz).
Beim Wechsel eines Empfängers bleibt der vorherige Empfänger bis zum Abschluss des letzten Commit's aktiv, erst danach wird er tatsächlich abgehängt und nach der nächsten Sicherung gelöscht.

Neue Commit's starten im neuen Empfänger.

Bei der Wiederherstellung ist jedoch genau darauf zu achten, den richtigen Empfänger zurückzuspeichern um die Journale abzuarbeiten.

Dies ist allerdings nur erforderlich, wenn man eine incrementelle Sicherung durchführt, so dass im Falle einer Wiederherstellung die Datenbank (bzw. die Lib's) geladen und anschließend die gesicherten Empfänger abgearbeitet werden.

[bie-dro]

Wenn ich das richtig verstehe, brauchen wir nichts zu unternehmen, da wir die Daten nicht inkrementell sichern.

Und wie müsste man vorgehen, wenn man die inkrementelle Sicherung nutzen möchte? Dürfte man dann die Journale nicht vom System verwalten lassen? Wie müsste man dann einen Journalempfänger wechseln?

Schönen Gruß

Artur Janzen

[Fuerchau]

Das geht nun schon in Datensicherungskonzepte und sprengt ggf. den Rahmen hier.

Nur kurz meine persönliche Meinung:

Um eine Wiederherstellung bei Systemausfall so kurz wie möglich zu gestalten, empfielt sich schon eine selbständige (auch automatisierbare) Überwachung von Journalen.

Hierzu kann man eine MSGQ nehmen, die z.B. eine Meldung für Schwellenüberschreitung eines Empfängers erhält.

So kann man per CLP den neuen Empfänger wechseln, warten bis der alte nicht mehr verwendet wird und ihn dann sofort sichern (nach Möglichkeit extern und nicht in eine SAVF).

Das Ganze zusätzlich noch Zeitüberwacht, so dass ggf. auch nach Ablauf der Zeit (z.B. 60 Minuten) der Empfänger wechselt und gesichert wird.

Dann eben täglich, wöchentlich oder sonstwie eine Komplettsicherung der Anwender-DB, je nach Sicherheitsbedürfnis.

Im Falle eines Crash's kann dann die letzte Komplettsicherung zurückgespielt werden und die gesicherten Empfänger per APYJRNCHG in der richtigen Reihenfolge aufgespielt, den DB-Zustand weitestgehend wiederherstellen.

Zu beachten ist hier nur ggf. die Laufzeit dieser Vorgänge und der damit verbundene Systemausfall.

Da sind dann viele HA-Lösungen dann häufig "günstiger", da sie die Ausfallzeiten drastisch minimieren und Journale ja dann sowieso nötig werden.