COMMIT WORK
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Der Unterschied ist welche Daten nach einem Rollback, Dump, Fehler, etc. bereits physikalisch auf der Datenbank gespeichert sind und welche nicht. Wann ein COMMIT WORK gesetzt wird musst du als Entwickler aus fachlicher und technischer Sicht entscheiden.
In der fachlichen Sicht muss geprüft werden, welche Daten logisch zusammenhängen und auch nur zusammen einen Sinn ergeben. Ein SD-Auftrag z.B. besteht aus Kopfdaten, Positionsdaten, Partnern, Texten, usw. Wenn während des Speicherns ein Problem auftritt macht es Sinn, dass der komplette Vorgang fehl schlägt und nicht z.B. nur die Positionsdaten ohne Kopfdaten gespeichert werden. Hier sollte also der COMMIT WORK erst nach vollständiger Speicherung des Gesamtobjekts erfolgen.
Aus technischer Sicht muss auch die Performance betrachtet werden. Wenn ich 500.000 Datensätze verarbeiten möchte macht es nicht Sinn nach jedem einzelnen Datensatz ein COMMIT WORK auszuführen. Hier müsste auch betrachtet werden wie bei einem Fehler ein Wiederholungslauf aussehen würde und ob überhaupt nachvollziehbar wäre, welche Datensätze bereits verarbeitet wurden oder ob ein kompletter Wiederholungslauf einfacher wäre. Andererseits kann es sehr nervig sein wenn ein einzelner fehlerhafter Datensatz die Speicherung aller 500.000 Datensätze verhindert hat - also alles eine Sache der Abwägung. Und Erfahrung.
In der fachlichen Sicht muss geprüft werden, welche Daten logisch zusammenhängen und auch nur zusammen einen Sinn ergeben. Ein SD-Auftrag z.B. besteht aus Kopfdaten, Positionsdaten, Partnern, Texten, usw. Wenn während des Speicherns ein Problem auftritt macht es Sinn, dass der komplette Vorgang fehl schlägt und nicht z.B. nur die Positionsdaten ohne Kopfdaten gespeichert werden. Hier sollte also der COMMIT WORK erst nach vollständiger Speicherung des Gesamtobjekts erfolgen.
Aus technischer Sicht muss auch die Performance betrachtet werden. Wenn ich 500.000 Datensätze verarbeiten möchte macht es nicht Sinn nach jedem einzelnen Datensatz ein COMMIT WORK auszuführen. Hier müsste auch betrachtet werden wie bei einem Fehler ein Wiederholungslauf aussehen würde und ob überhaupt nachvollziehbar wäre, welche Datensätze bereits verarbeitet wurden oder ob ein kompletter Wiederholungslauf einfacher wäre. Andererseits kann es sehr nervig sein wenn ein einzelner fehlerhafter Datensatz die Speicherung aller 500.000 Datensätze verhindert hat - also alles eine Sache der Abwägung. Und Erfahrung.
Beitrag
von a-dead-trousers (Top Expert / 4413 / 224 /
1185
)
»
COMMIT [WORK] betrifft Datenbank Transaktionen im allgemeinen und da muss man immer die logische Zusammengehörigkeit von Datenbankoperationen berücksichtigen:
https://www.datenbanken-verstehen.de/da ... ansaktion/
http://www.it-infothek.de/sql/transakti ... rheit.html
Bei ABAP kommt speziell bei Verwendung von Dynpros noch das "implizite" Commit zwischen PAI/PBO dazu. Das heißt, dass alle Datenbank Operationen die zwischen PAI und PBO eines Dynpros ausgeführt werden, auch ohne COMMIT WORK auf die Datenbank angewendet werden. Das gleiche gilt auch beim (fehlerfreien) Beenden eines Programms.
Zudem kennt ABAP auch noch eine sogeannte Verbuchung, die explizit nur mit COMMIT WORK ausgeführt wird, um die erwähnten "impliziten" Commits zu umgehen.
https://www.datenbanken-verstehen.de/da ... ansaktion/
http://www.it-infothek.de/sql/transakti ... rheit.html
Bei ABAP kommt speziell bei Verwendung von Dynpros noch das "implizite" Commit zwischen PAI/PBO dazu. Das heißt, dass alle Datenbank Operationen die zwischen PAI und PBO eines Dynpros ausgeführt werden, auch ohne COMMIT WORK auf die Datenbank angewendet werden. Das gleiche gilt auch beim (fehlerfreien) Beenden eines Programms.
Zudem kennt ABAP auch noch eine sogeannte Verbuchung, die explizit nur mit COMMIT WORK ausgeführt wird, um die erwähnten "impliziten" Commits zu umgehen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4413 / 224 /
1185
)
»
Das kommt ganz auf die Anwendungs- und somit auf die Transaktionslogik an, die man abbilden möchte.
Für eine explizite Unterscheidung zwischen Z- und SAP-Tabellen gibt es hier keinen Grund.
Für eine explizite Unterscheidung zwischen Z- und SAP-Tabellen gibt es hier keinen Grund.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Wenn ich DB-Änderungen durchführe mache ich IMMER abschließend entweder ROLLBACK oder COMMIT. Oder bei Änderungen via BAPI die zugehörigen BAPI-Fubas. M.E. gehört das saubere Abschließen einer DB-Operation zu einem guten Programmierstil.
Es gibt diverse Unterschiede, die meine Vorredner ja schon angesprochen haben. Aber es gibt so ein paar Anhaltspunkte, an die man sich grob halten sollte:
- Transaktionale Daten: Erst alles speichern, wenn ALLES fehlerfrei war - COMMIT, sonst ROLLBACK
- Massenänderungen die "schnell" erledigt sind mit "wenig Datenvolumen": Ein einzelner COMMIT (spart Laufzeit ).
- Massenänderungen mit "viel Datenvolumen": Periodischer COMMIT, da der DB-Buffer hier an seine Grenzen gelangen könnte und daraus dann Laufzeitprobleme kommen können
- Massenänderungen in einem länger laufenden Prozess: Periodischer COMMIT, da sonst irgendwann Sperrprobleme in anderen Prozessen auftreten, die auch auf die Daten zugreifen und darauf warten, dass du dich entscheidest ob die Daten persistiert werden sollen oder eben nicht
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Danke für die Antworten.
ich habe bisher Z-Tabellen ohne COMMIT WORK ausgeführt. Würde ich ab sofort ändern.
Soll man so ein Update immer mittels Z-Verbunchungsbausteine für Z-Tabellen machen? Was ist der Unterschied, wenn man kein Verbuchungsbaustein verwendet?
Was ich noch nicht ganz vertanden habe:
Wenn man auf die Datenbankgeschrieben hat, geschieht die Verbuchung erst nach dem COMMIT, aber was genau bedeutet VERBUCHUNG? ich dachte immer auf die Datenbank erfolgreich schreiben ist das selbe wie Verbuchung.
ich habe bisher Z-Tabellen ohne COMMIT WORK ausgeführt. Würde ich ab sofort ändern.
Soll man so ein Update immer mittels Z-Verbunchungsbausteine für Z-Tabellen machen? Was ist der Unterschied, wenn man kein Verbuchungsbaustein verwendet?
Was ich noch nicht ganz vertanden habe:
Wenn man auf die Datenbankgeschrieben hat, geschieht die Verbuchung erst nach dem COMMIT, aber was genau bedeutet VERBUCHUNG? ich dachte immer auf die Datenbank erfolgreich schreiben ist das selbe wie Verbuchung.
Es ist völlig egal, ob Z-Tabellen oder sonst welche. Nur mit ein COMMIT werden die Daten auf der DB persistiert.
Das kann auch ein implizites COMMIT sein, z.B. wenn der Report einen Bildwechsel macht und ich meine auch, wenn man ein Success-Meldung absetzt.
Verbuchen im SAP-Sinne ist, wenn du einen Fuba im UPDATE TASK ruft. Dieseer wird dann erst ausgeführt, wenn du ein COMMIT machst. Das nutzt man z.B. für Änderungsbelege, weil diese u.U. länger dauern und man den Anwender nicht warten lassen will. Nimmt man trotz Verbucher-Fuba ein COMMIT WORK AND WAIT, so muss der Anwender trotzdem warten, bis der Verbuchungsprozess (= Ausführung des Fuab) fertig ist.
Das kann auch ein implizites COMMIT sein, z.B. wenn der Report einen Bildwechsel macht und ich meine auch, wenn man ein Success-Meldung absetzt.
Verbuchen im SAP-Sinne ist, wenn du einen Fuba im UPDATE TASK ruft. Dieseer wird dann erst ausgeführt, wenn du ein COMMIT machst. Das nutzt man z.B. für Änderungsbelege, weil diese u.U. länger dauern und man den Anwender nicht warten lassen will. Nimmt man trotz Verbucher-Fuba ein COMMIT WORK AND WAIT, so muss der Anwender trotzdem warten, bis der Verbuchungsprozess (= Ausführung des Fuab) fertig ist.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Bei Z-Tabellen kannst Du machen, was Du willst. Das ist Deine eigene Tabelle; da gibt es keine Konsistenzabhängigkeiten mit dem SAP-Standard, die eine Rolle spielen könnten.
Die "Verbuchung" im SAP-Sinne hat msfox gut beschrieben. Im allgemeinen Sinne bedeutet "Verbuchung", dass Änderungen zunächst nur in einen Puffer gepackt und erst später (nämlich bei der Verbuchung) auf die Datenbank geschrieben werden, und zwar auf SAP-Ebene (und nicht wie beim COMMIT auf Datenbankebene).
Wie schon erwähnt, habe ich mir ein eigenes Verbucher-Framework programmiert, auf das ich sehr stolz bin und das sehr gut funktioniert. Es ist immer dann nützlich, wenn die Daten nicht sofort in Deinem Code geändert werden können, beispielsweise weil da irgendwelche Sperren drauf liegen. Dann stellt mein Programm einen "Verbucher-Task" in mein Verbucher-Framework ein. Dieser "Task" ist nichts anderes als der Name einer Methode zusammen mit passenden Parametern für diese Methode. Dies wird in einer Tabelle der auszuführenden Tasks gespeichert. Alle 3 Minuten startet das Verbucher-Framework als Job und schaut nach, ob offene Tasks anliegen. Wenn ja, dann versucht es, diese Methode mit diesen Parametern aufzurufen. Die Methode (die natürlich gleichfalls von mir ist) versucht dann, die Werte zu schreiben. Klappt das, liefert sie einen leeren Errorstring zurück, und das Verbucherframework setzt den Task auf "erledigt". Klappt es nicht, liefert die Methode eine entsprechende Nachricht im Errorstring zurück (z.B. "Personalnummer gesperrt von Benutzer xyz"). Das Verbucherframework lässt den Task dann offen und probiert es beim nächsten Mal erneut. Dabei gibt es einen Timeout, dass ein Task, der eine gewisse Anzahl von Stunden nicht erfolgreich ausgeführt werden konnte, als final gescheitert angesehen wird.
Außerdem merkt sich das Verbucherframework in einer DB-Tabelle, welchen Task es gerade bearbeitet, bevor es die Methode startet. Sollte die Methode crashen (Dump oder anderweitig nicht die Kontrolle an das rufende Programm zurückgegeben), dann wird dies 3 Minuten später beim nächsten Verbucherframework-Lauf erkannt und dieser Task auf "crashed" gesetzt und nicht mehr ausgeführt. Die übrigen offenen Tasks, die ggf. durch diesen Crash nicht ausgeführt werden konnten, laufen dann also 3 Minuten später, was in aller Regel kein Drama ist.
Über eine Verbucher-Admin-Transaktion kann man sich jederzeit alle Tasks mit ihren jeweiligen Status anschauen und auch bei gescheiterten oder gecrashten Tasks manuell einen Retry anstoßen. Dadurch ist diese Admintransaktion ein vollwertiges Log, so dass ich in der SM37 keine Joblogflut für den alle drei Minuten laufenden Verbucherjob benötige. Daher hat dieser einen zweiten Step, der immer das Log vom vorherigen Lauf löscht, so dass die SM37 sauber bleibt und das Joblog nicht über Gebühr belastet wird.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
whaslbeck
...und dabei der gesamte Code in dem Funktionsbaustein ausgeführt wird. Es muss also nicht zwingend ein Schreiben auf der Datenbank sein.DeathAndPain hat geschrieben: ↑28.05.2023 16:16und erst später (nämlich bei der Verbuchung) auf die Datenbank geschrieben werden,
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Na ja, ein im Hintergrund laufender Code, der effektiv nichts auf der Datenbank ändert, der macht letztlich gar nichts. Mal abgesehen von Randfällen wie dem Setzen eines Wertes im ABAP Memory.
Statt auf der DB zu schreiben, kann man z.B. auch Protokoll ins Filesystem* schreiben o.ä.. Man kann(!) auch Prüfungen über den Verbucher machen und ein Abbruch provozieren. Ob das jetzt sinnhaft ist, muss jeder selbst entscheiden.
Kurz: Der Verbucher muss sich nicht auf rein DB-Zugriff beschränken.
--
*Konkret habe ich so etwas gebaut, dass Änderungen in eine CSV-Datei geschrieben werden und eine andere Anwendung (c.B. CMS) diese Daten abholt. War ein Kundenauftrag.
Kurz: Der Verbucher muss sich nicht auf rein DB-Zugriff beschränken.
--
*Konkret habe ich so etwas gebaut, dass Änderungen in eine CSV-Datei geschrieben werden und eine andere Anwendung (c.B. CMS) diese Daten abholt. War ein Kundenauftrag.
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
2130
Views
Views
2
Antw.
Antw.
5398
Views
Views
0
Antw.
Antw.
1440
Views
Views
3
Antw.
Antw.
3267
Views
Views
16
Antw.
Antw.
3721
Views
Views
Wie benutze ich COMMIT WORK richtig
von ABAPlerv » 18.04.2024 22:18 • Verfasst in ABAP® für Anfänger
von ABAPlerv » 18.04.2024 22:18 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 471
vor 23 Stunden von a-dead-trousers 5 / 471
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 471
vor 23 Stunden von a-dead-trousers 5 / 471