Auswirkungen durch länger andauerndes COMMIT

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
15 Beiträge • Seite 1 von 1
15 Beiträge Seite 1 von 1

Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Job:
Step 1: ZREP1 - baut Datenbestand auf (ab 100.000 Sätze)
Step 2: ZREP2 - direkt hinterher, benutzt Ausschnitt der oben erstellten Daten

Es scheint manchmal so zu sein, dass ZREP2 keine Daten findet obwohl ZREP1 sie angelegt hat. Die Vermutung ist, dass der COMMIT (einziger ganz am Ende) auf der DB noch nicht beendet ist während ZREP2 schon angelaufen ist.

a) Kann das sein, jemand schonmal so einen Fall gehabt?
b) wenn ja, gibt es eine Möglichkeit mit ABAP die DB abzufragen ob der COMMIT durch ist? Ein wait ginge ja, aber habe keinen Schimmer wie lange ein COMMIT braucht und wie ich das feststellen kann. Egal wen ich frage keiner ist sich sicher, vermuten alle genau so wie ich 🙂

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Wenn der Datenbestand durch einfaches INSERT in die DB-tabelle erzeugt wird, wüsste ich nicht, woran das liegen kann.
Wenn du allerdings z.B. Belege(oder andere Objekte) per BAPI erstellst, dann werden diese mit hoher Wahrscheinlichkeit verbucht. Das kann durchaus länger dauern, da die Daten dann asynchron über einen Verbucher-Prozess erzeugt werden.
Das kannst du umgehen, indem du vor jeden BAPI-Aufruf den Befehl SET UPDATE TASK LOCAL setzt.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Nein, kein Verbucher und keine Bapis, es ist einfach ein modify Ztab from table itab die halt sehr groß sein kann. Habe inzwischen ein Testprogramm gemacht und generiere x Datensätze in 2 Tabellen ... und staune, selbst wenn ich 200.000 Sätze generiere wird der COMMIT praktisch sofort durchgeführt, man merkt keine Verzögerung, wieso ist das Festschreiben in der DB so schnell?

Ich probiere gleich mal ein ROLLBACK: wenn das lange läuft, dann habe ich den Fortschreibungsprozess der DB nicht verstanden.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von jocoder (Specialist / 338 / 3 / 101 ) »
Ein COMMIT WORK ohne WAIT ist immer asynchron. D.h. das ABAP-Programm läuft weiter, obwohl der COMMIT WORK noch nicht fertig ist. Daher würde ich hier einfach COMMIT WORK AND WAIT verwenden.

Die Zeitdauer kannst du durch eine Messung feststellen. Hier hilft u.U. die Laufzeitmessung in der SAT oder der DB-Trace in ST05.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Das WAIT zieht nur beim Verbucher, den benutze ich jedoch nicht, ganz normales SQL Modify. Stimmt, Trace sollt eich mal probieren vlt gibts da mehr Infos

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
deejey hat geschrieben:
16.04.2020 12:01
Das WAIT zieht nur beim Verbucher
Und auch das nur unter bestimmten Voraussetzungen, die ich nicht verstanden habe.
https://blogs.sap.com/2013/01/24/commit ... x-seconds/

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
ewx hat geschrieben:
16.04.2020 12:05
deejey hat geschrieben:
16.04.2020 12:01
Das WAIT zieht nur beim Verbucher
Und auch das nur unter bestimmten Voraussetzungen, die ich nicht verstanden habe.
https://blogs.sap.com/2013/01/24/commit ... x-seconds/
omg was für ein Riesentext und dann auch noch in englisch ... ziehe es mir nachher rein, vlt gibt da eine Anregung für mein Problem

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von jocoder (Specialist / 338 / 3 / 101 ) »
Warum baust du dir nicht selber einen Verbuchungsbaustein? Damit sollte es doch klappen.
Oder eine alternative Lösung: die MODIY und COMMIT Anweisung portionsweise ausführen

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
jocoder hat geschrieben:
16.04.2020 18:41
Warum baust du dir nicht selber einen Verbuchungsbaustein? Damit sollte es doch klappen.
Oder eine alternative Lösung: die MODIY und COMMIT Anweisung portionsweise ausführen
Das geht nicht, es warten Folgeprogramme die sofort nach Programmende anlaufen, die brauchen die Daten sofort. Und diese finden manchmal Sätze nicht, die im Vorprogramm definitiv angelegt wurden. Meine Vermutung war daher dass die DB noch nicht fertig fortgeschrieben war. Der Verbucher bringt nichts weil auch er diese Updates macht und sich beendet wenn er durch ist, was aber nicht bedeuten muss dass die DB auch fertig mit COMMIT ist.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Mein Problem ist also nicht genau zu wissen ob es die Situation geben kann, dass nach einem MODIFY von sehr vielen Sätzen, COMMIT und Programmende die DB noch eine gewisse Zeit mit dem Festschreiben der Änderungen beschäftigt ist.

Die Fehlersituation deutet darauf hin, ich kann das aber nicht nachweisen und auch keine Doku dazu finden die sowas beschreibt.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ich halte das für ein Gerücht, dass das AND WAIT nur bei Verbuchernutzung einen Effekt hat. Wenn man selber per UPDATE, MODIFY, INSERT oder DELETE auf einer (hoffentlich kundeneigenen) Datenbank-Tabelle eine Änderung vornimmt und im Anschluss einen COMMIT WORK AND WAIT macht, dann habe ich es noch nie erlebt, dass die Änderungen danach nicht auf der Datenbank gestanden hätten. Das widerspricht auch nicht dem verlinkten SAP-Artikel.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Es steht doch auch gar nicht zur Debatte, dass ein COMMIT AND WORK ausschließlich für Verbucher gilt. 🤨 AND WAIT ist jedoch nur für Verbucher relevant.

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Genau das ist es, was ich bestreite - es sei denn, Du betrachtest die Arbeit der Datenbank selbst auch schon als Verbuchung. Mit COMMIT WORK schließt Du die Transaktion ab und übergibst sie der Datenbank zur Verbuchung. Mit dem AND WAIT stellst Du sicher, dass die Daten tatsächlich fertig geschrieben auf der Datenbank stehen, bevor Du weitermachst.

Für Deinen aktuellen Prozess ist dies nicht relevant. Wenn Du einen INSERT machst und gleich im Anschluss den Wert wieder mit SELECT liest, dann bekommst Du ihn, als ob er schon auf der Datenbank stünde. Das bedient die Datenbank aus dem Puffer. Für andere Prozesse gilt dies jedoch nicht (wenn Du z.B. mit SUBMIT VIA JOB einen Unterreport als eigenständigen Prozess starten möchtest, der dann mit den Daten weiterarbeiten soll, die Du gerade geschrieben hast, was voraussetzt, dass er sie auch finden kann).

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von gtoXX (Specialist / 185 / 34 / 31 ) »
Ich war geneigt dir zu zustimmen DAP.

Die Rückgabewerte für sy-subrc beziehen sich nach Doku von SAP jedoch auf die Verbuchungsbausteine. Das ist aber nach einem kurzen 7.40 Testprogramm auch irreführend.
https://help.sap.com/doc/abapdocu_750_i ... commit.htm
"Code lügt nicht ^^"

Re: Auswirkungen durch länger andauerndes COMMIT

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Der aktuelle Prozess findet natürlich alles was er selbst erzeugt, auch vor dem COMMIT, das war nicht mein Problem. Aber inzwischen habe ich folgende Tatsache durch Tests herausgefunden (zumindest unter Oracle):

- generiere 300.000 Sätze in Z-Tabelle
- ein anderes Programm im Hintergrund prüft permanent sekündlich ob ein bestimmter Satz da ist
- wenn Inserts fertig COMMIT
- praktisch sofort findet das Batchprogramm den Satz und beendet sich

Es ist nicht zu leugnen, der COMMIT zieht praktisch sofort, ob nun 200.000 oder 400.000 Sätze. Jetzt der gleiche Test mit ROLLBACK: dieser dauert mehrere Minuten. Das kann nur das bedeuten, was eigentlich auf der Hand liegt: die DB geht optimistisch vor und speichert die Daten gleich in die Tabellen, verwaltet aber irgendwo Infos über Satzsperren und COMMIT-Status. Wenn nun COMMIT ausgeführt wird, einfach diese internen Verwaltungsdaten löschen und fertig, während bei ROLLBACK tatsächlich Sätze entfernt oder als gelöscht markiert werden müssen. Anders ist es nicht erklärbar.

Seite 1 von 1

Vergleichbare Themen

0
Antw.
1715
Views
Auswirkungen Nichtabarbeiten COGI Liste
von Abraxas1 » 01.02.2008 16:42 • Verfasst in Financials
2
Antw.
2071
Views
Negative Auswirkungen EA-HR Human Resources Extension ???
von Stentor » 27.10.2004 10:00 • Verfasst in Human Resources
0
Antw.
842
Views
Keine Auswirkungen beim Programm ausführen
von gogi » 16.01.2008 08:00 • Verfasst in ABAP® Core
3
Antw.
2182
Views
COMMIT
von alex1986 » 07.09.2011 14:45 • Verfasst in ABAP® für Anfänger
11
Antw.
482
Views
COMMIT WORK
von retsch » 25.05.2023 07:40 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141