Zitat Zitat von Fuerchau Beitrag anzeigen
Wie gesagt, bei dieser ERP-Software ist der Einsatz von Journalen illusorisch da einfach die Kapazitäten nicht ausreichen. So viele Bänder, wie da pro Tag anfallen kann man gar nicht anschaffen und wer kann schon in Millionen Pseudoupdates (Flagfelder) genau den Verursacher der Fehler finden ins besonders wenn man Tage allein zum Zurückladen und durchsuchen der Journale benötigt.

Für Neuanwendungen bzw. Ergänzungen mit eigenen Tabellen (ohne Bezug zu bestehenden Daten) macht das durchaus Sinn.
Da aber leider doch immer Abhängigkeiten zur Anwendung bestehen lassen sich auch hier die neuen Tabellen nicht sinnvoll unter Commit stellen, da ja die alten Tabellen nicht journalisiert sind.

Aber ich glaube, hier unterscheiden sich halt die Meinungen gravierend.
Das würde ich so nicht unterschreiben!

Man kann jederzeit mit Journaling und Commitment Control auf JEDER Maschine anfangen.
Zu Beginn kann man durchaus mit "Schmalspur"-Journaling verwenden, d.h. alle Dateien werden aufgezeichnet, die JournalReceiver (relativ) klein gehalten und sofort nach dem Abhängen gelöscht (geht automatisch mit der entsprechenden Einstellung).

Da eine Transaktion nicht über mehrere Journal-Receiver verteilt wird, kann Commitment Control für neue Programme (und alte Dateien) eingesetzt werden, während die bestehenden Programme sich verhalten wie zuvor.

Auch wenn in diesem Statium ein Nachfahren nicht möglich ist, wird dennoch (zumindest bei den neuen Programmen) Transaktions-Sicherheit gewährleistet werden.

Später kann man dann das Ganze immernoch so ändern, dass die Receiver vor dem Löschen auf Band gezogen oder für Hochverfügbarkeit auf eine andere Maschine übertragen werden. Dann kann Journaling auch wirklich dazu verwendet werden im Falle eines Crashs entweder alles Nachzufahren oder auf die andere Maschine zu switchen.

Birgitta