Create Schema / Table -> Jounale

[BenderD]

DTAARA's können nicht journalisiert werden.
Z.B. sind Sequence-Objekte über DTAARA's realisiert, werden nicht journalisiert und können auch nicht per Rollback zurückgesetzt werden. Dies wäre ja auch fatal da ja parallele Transaktionen sonst ganz schön durcheinander kämen.

DTAARAs kann man journalisieren (ebenso wie DataQs), STRJRNOBJ ist Dein Freund; mit Rollback hat das erst mal nix zu tun, das geht freilich nicht, da das ja SQL ist.

D*B

[Fuerchau]

OK, wieder was gelernt.
Ob die Daten da aber im Rollbck-Fall (gibts auch als CMD) auch zurückgedreht werden?
Bleibt eine Sperre bis zum Commit auf dem Objekt?
Werden die Daten bei einer DTAQ gepuffert und erst beim Commit tatsächlich gesendet und beim Rollback verworfen?
Ansonsten erleichtert das nur die Nachvollziehbarkeit von Daten.

[malzusrex]

Ich danke erst einmal bis hier hin.
Ich schaue mir das alles mal an.
Commit / Rollback soll da nicht das Problem sein. Wird imm Moment nicht genutzt.
Mir geht es hauptsächlich ersteinmal darum, zu schauen wer (oder welches Programm) im Zweifel etwas geändert hat. Bisher habe ich das Über Trigger oder Protokolldateien im Programm gelöst. Aber warum nicht Journale nutzen, wenn die das besser können..

Gruß
Ronald

[Fuerchau]

Das kommt halt auf die Anwendung an.
Nimm mal z.B. die Anwendung XPPS(RH/Brain/Infor).
Hier werden "logische" Satzsperren über USER/WRKSTN-Felder gelöst.
Dies löst natürlich sehr viele Jornaleinträge aus obwohl sich ansonsten nichts ändert.
Wir hatten das vor Jahren mal kurzfristig gestestet und in 1 Stunde bereits 1 GB Journal.
Somit wurde halt Trigger geschrieben, die die Aufzeichnung nur bestimmter wichtiger Felder vornahm.
Aber es liegt halt "im Auge des Betrachters".

Für die Auswertung von Journalen hat D*B auf seiner Seite auch ein schönes Tool.

[BenderD]

@Baldur: das journalisieren von DTAARA und DataQ ist wohl für die Glaubensgemeinschft der Software Spiegler (die glauben alle, dass sie umschalten können, wenn ihre Maschine abraucht) implementiert worden. Commit und Rollback wird da nicht unterstützt, wer das haben will, muss das selber implementieren (commit exit ist euer Freund).

Datenvolumen der Journale ist grundsätzlich kein Argument, das ist doch nur ein Durchlaufpuffer und den kann man (fast) beliebig minimieren, inklusive vorheriges sichern auf Band, alles voll elektrisch, versteht sich.

Dieter

[Fuerchau]

Zu letzterem:
Das wurde deshalb wieder abgeschaltet da durch die Menge der anfallenden Daten und die Automatismen eben veränderte Daten bereits nach wenigen Stunden nicht mehr rekonstruierbar waren. Sie waren schlichtweg im Überlauf verschwunden.
Trigger haben sich da (und das ist unabhängig vom Journal) als die sauberere Lösung erwiesen.
Zumal unter dem Stichwort "wer hat den Trigger ausgelöst" das Journal nicht hilfreich ist wenn Filehandler im Spiel sind. Hier musste ich halt oberhalb des Filehandlers im Stack nachsehen, welches Programm denn das war. Im Journal steht immer nur der Filehandler als Verursacher.

[BenderD]

... das gehört aber alles (incl. Brai/Infor) in die Abteilung Datenschrank und nicht Datenbank...

[Pikachu]

Suche mal nach QDFTJRN. Siehe auch dieses Thema.