Journalempfänger sichern

[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.