Datensatz aus PF gelöscht - Wie Protokollieren?

[ILEMax]

Ich möchte wissen bevor ich eine Tabelle umstelle wie viele Änderungen an einer Table stattfinden

Ich vermute, das dafür die Künstliche Inteligenz erfunden wurde.
Hieß früher Glaskugel.

Sorry ...

[BenderD]

Hi Andreas,

sorry da habe ich mich etwas falsch ausgedrückt.

Ich möchte wissen bevor ich eine Tabelle umstelle wie viele Änderungen an einer Table stattfinden

Gruß Michael

... Journal und jeweils vor löschen des Receivers auswerten. Dabei sollte man im Auge haben, dass Reorg oder Jahresend Programme sich da "speziell" verhalten könnten.

D*B

[holgerscherer]

Hallo zusammen,

zum Thema Temporal Table

Haben wir auf der IBM i eine Möglichkeit die Anzahl der updates und Inserts einer Tabelle auszuwerten ?

Die Performance-Datensammlung bietet hier eine Menge Daten. Es ist allerdings hilfreich, auf einem aktuellen Release (V7R3, V7R4,...) zu sein und mit dem neuen Navigator ein wenig rumzuklicken. Den Rest liefert iACS.

-h

[holgerscherer]

Journale helfen nur dann, wenn Verluste noch vor dem Reorg der Journale festgestellt werden können.

Wenn man Journale korrekt und sinnig einsetzt, dann
a) reorganisiert man die Receiver nicht, sondern hebt sie auf, und
b) hat eine Software, die selbst aus den Receivern selektiv Löschungen wieder rückgängig machen kann

Geht alles, wenn man will. Produktnamen nenne ich natürlich nicht.

[Fuerchau]

Nun ja, wenn man genug Platz hat und Journale nicht ausschließlich für Transaktionen verwendet, dann gebe ich Dir Recht.
Aber häufig wird der Verlust eher nach dem Motto "Hatten wir da nicht mal ....?" bemerkt.
Über den zu archivierenden Zeitraum muss man da mal nachdenken.

Frei nach dem Motto: Die goldenene 20er sind ja jetzt wieder da.

[holgerscherer]

Nun ja, wenn man genug Platz hat und Journale nicht ausschließlich für Transaktionen verwendet, dann gebe ich Dir Recht.
Aber häufig wird der Verlust eher nach dem Motto "Hatten wir da nicht mal ....?" bemerkt.
Über den zu archivierenden Zeitraum muss man da mal nachdenken.

Die goldenen 20er - die Zeiten günstigen Plattenplatzes ;-) Man kann die Transaktionen ja auch externalisieren. Und der Verhältnis von "verbrauchtem Platz für Journale" zu "Größe des Betriebs" ist in der Regel recht positiv für Journalisierung, bedenkt man, was viele Firmen an Plattenplatz für eher sekundärwichtigen Sachen verballern.

[BenderD]

Wenn man Journale korrekt und sinnig einsetzt, dann
a) reorganisiert man die Receiver nicht, sondern hebt sie auf, und
b) hat eine Software, die selbst aus den Receivern selektiv Löschungen wieder rückgängig machen kann

Geht alles, wenn man will. Produktnamen nenne ich natürlich nicht.

... Haupt Einsatzzweck von Journalisierung ist der Einsatz von Commitment Controll, was bedeutet, dass man alle Dateien journalisieren sollte. Netter Nebeneffekt ist, dass die Journale für Fehler-Analyse und -Korrektur genutzt werden können. Das Datenvolumen übersteigt allerdings jeden verfügbaren Plattenspeicherplatz, das ist nur eine Frage der Zeit.
Best Practice ist hier, die Journal Receiver für 2 bis 3 Tage aufzuheben und dann zu archivieren. Im Großrechner Bereich hat man dann HSM im Einsatz, das die Verlagerung automatisiert und die Archiv Bestände auch automatisch zurückholt, wenn auf sie zugegriffen wird. Im Unix Umfeld hat man das auch öfter, im AS400 Umfeld könnte man BRMS an einen TSM Server ankoppeln, habe ich aber noch nirgends im Einsatz gefunden.
Zur Historisierung von Daten sind Journal Receiver nicht geeignet, da fehlt es an Verknüpfungsmöglichkeiten. In früheren Zeiten hat man die JRNRCVs verwendet, um Daten zu historisieren, aktuell setzt man da eher auf die Historisierung im DB2 (was viel zu selten genutzt wird).

D*B