Auswirkungen durch länger andauerndes COMMIT
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
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 🙂
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
kostenfrei für Ausbildungsberufe und Werksstudenten
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.
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.
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.
Ich probiere gleich mal ein ROLLBACK: wenn das lange läuft, dann habe ich den Fortschreibungsprozess der DB nicht verstanden.
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.
Die Zeitdauer kannst du durch eine Messung feststellen. Hier hilft u.U. die Laufzeitmessung in der SAT oder der DB-Trace in ST05.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
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 Problemewx hat geschrieben: ↑16.04.2020 12:05Und auch das nur unter bestimmten Voraussetzungen, die ich nicht verstanden habe.
https://blogs.sap.com/2013/01/24/commit ... x-seconds/
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
Oder eine alternative Lösung: die MODIY und COMMIT Anweisung portionsweise ausführen
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
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.
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.
Die Fehlersituation deutet darauf hin, ich kann das aber nicht nachweisen und auch keine Doku dazu finden die sowas beschreibt.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.
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.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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).
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).
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
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 ^^"
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.
- 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.
Antw.
1840
Views
Views
0
Antw.
Antw.
925
Views
Views
13
Antw.
Antw.
1147
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.