DB Tabelle per asynchronem RFC löschen - kein Zeitvorteil(?)
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo Zusammen, ich muss doch hier mal bei den Experten nachfragen:
Gegeben ist eine DB Tabelle, die täglich mit ca. 6 Mio. Einträgen gefüllt wird.
Das Feld IMPORT_DATE ist gleichzeitig auch Schlüsselfeld. Alle 7 Tage sollen die alten Einträge gelöscht werden ( import_date = sy-datum - 7). Also selektiere ich vorher die relevanten Schlüssel in eine int. Tabelle.
Ich habe verschiedene Varianten ausprobiert, um das Löschen beschleunigen:
Es ergibt sich kein nennenswerter Unterschied in den Laufzeiten der Jobs.
Ich setze beim klassischen Ansatz nach jedem Block ein COMMIT WORK ab, beim asynchronen Ansatz wird das doch implizit auch abgesetzt(?), sollte also dieselbe Wirkung haben.
Ist der Overhead so groß beim asynchronen Aufruf, oder ist die DB der Flaschenhals?
Hat jemand ähnliche Erfahrungen?
Erstmal schönes Wochenende 😊
Frank
Gegeben ist eine DB Tabelle, die täglich mit ca. 6 Mio. Einträgen gefüllt wird.
Das Feld IMPORT_DATE ist gleichzeitig auch Schlüsselfeld. Alle 7 Tage sollen die alten Einträge gelöscht werden ( import_date = sy-datum - 7). Also selektiere ich vorher die relevanten Schlüssel in eine int. Tabelle.
Ich habe verschiedene Varianten ausprobiert, um das Löschen beschleunigen:
- Klassischer Ansatz:
Code: Alles auswählen.
DELETE dbtab FROM TABLE im_dbtab_keys.
- asynchroner Ansatz in 5 parallelen Aufrufen
Es ergibt sich kein nennenswerter Unterschied in den Laufzeiten der Jobs.
Ich setze beim klassischen Ansatz nach jedem Block ein COMMIT WORK ab, beim asynchronen Ansatz wird das doch implizit auch abgesetzt(?), sollte also dieselbe Wirkung haben.
Ist der Overhead so groß beim asynchronen Aufruf, oder ist die DB der Flaschenhals?
Hat jemand ähnliche Erfahrungen?
Erstmal schönes Wochenende 😊
Frank
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Gibt's einen Grund warum du die Schlüssel vorher selektierst und nicht sofort mit der Bedingung löscht?
Bei den Daten Mengen wäre es vielleicht sinnvoll direkt auf der db zu löschen, weiß aber nicht welchen impakt sowas generell haben könnte.
Bei den Daten Mengen wäre es vielleicht sinnvoll direkt auf der db zu löschen, weiß aber nicht welchen impakt sowas generell haben könnte.
Hallo ST22,
gibt es auch ein Feld mit Uhrzeit? Wenn ihr jede Stunde einen DELETE Job laufen lässt, dann sind es nur noch 250000 zu löschende Datensätze pro Durchlauf.
Mit freundlichen Grüßen
Matthias Alpmann
gibt es auch ein Feld mit Uhrzeit? Wenn ihr jede Stunde einen DELETE Job laufen lässt, dann sind es nur noch 250000 zu löschende Datensätze pro Durchlauf.
Mit freundlichen Grüßen
Matthias Alpmann
Danke für eure Hinweise, aber mich wundert halt einfach, dass die parallele Verarbeitung nicht deutlich schneller ist, als die sequentielle.
Generell wird einmal am Tag importiert und einmal am Tag gelöscht.
Da das Feld IMPORT_DATE schon im Tabellenschlüssel ist, denke ich ist das schon mal gut, darüber zuzugreifen.
Ich selektiere vorher die Schlüssel, um den ROLLBACK Bereich der DB klein zu halten. Aber wie gesagt, das mache ich bei beiden Varianten identisch.
VG
Generell wird einmal am Tag importiert und einmal am Tag gelöscht.
Da das Feld IMPORT_DATE schon im Tabellenschlüssel ist, denke ich ist das schon mal gut, darüber zuzugreifen.
Ich selektiere vorher die Schlüssel, um den ROLLBACK Bereich der DB klein zu halten. Aber wie gesagt, das mache ich bei beiden Varianten identisch.
VG
Beitrag
von a-dead-trousers (Top Expert / 4295 / 214 /
1146
)
»
Du sagst es ja selber schon:
Der ROLLBACK Bereich der DB ist hier der limitierende Faktor.
Du kannst das ganze so parallel wie möglich ausführen, am Ende läuft alles auf derselben Datenbank ab. Der Umstand, dass es bei der parallelen Ausführung nicht wirklich signifikant schlechter läuft (mehrere DB-LUWs) sagt eigentlich schon wie gut (im positiven Sinn) eure Datenbank konfiguriert ist und das es eben nicht schneller gehen wird.
Einzige Möglichkeit wäre, das Undo-Log auszuschalten aber davon würde ich tunlichst abraten.
Der ROLLBACK Bereich der DB ist hier der limitierende Faktor.
Du kannst das ganze so parallel wie möglich ausführen, am Ende läuft alles auf derselben Datenbank ab. Der Umstand, dass es bei der parallelen Ausführung nicht wirklich signifikant schlechter läuft (mehrere DB-LUWs) sagt eigentlich schon wie gut (im positiven Sinn) eure Datenbank konfiguriert ist und das es eben nicht schneller gehen wird.
Einzige Möglichkeit wäre, das Undo-Log auszuschalten aber davon würde ich tunlichst abraten.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ST22
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
Moin,
aber genau da hätte ich vermutet, dass der implizite COMMIT oder aber auch ein expliziter (im RFC Baustein) dieses Problem beseitigt.
Ich dachte, mit dem COMMIT werden auch die UNDO Logs gelöscht oder zurück gesetzt.
Nun denn, wieder was gelernt ;-)
Grüße
Frank
aber genau da hätte ich vermutet, dass der implizite COMMIT oder aber auch ein expliziter (im RFC Baustein) dieses Problem beseitigt.
Ich dachte, mit dem COMMIT werden auch die UNDO Logs gelöscht oder zurück gesetzt.
Nun denn, wieder was gelernt ;-)
Grüße
Frank
Beitrag
von a-dead-trousers (Top Expert / 4295 / 214 /
1146
)
»
Ja, aber die Logs müssen auch irgendwann mal (auf die Festplatte) geschrieben werden. Und das ist bei dieser großen Datenmenge nun mal der Knackpunkt.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ST22
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
Seite 1 von 1
Vergleichbare Themen
9
Antw.
Antw.
3446
Views
Views
4
Antw.
Antw.
14392
Views
Views
14
Antw.
Antw.
9880
Views
Views
1
Antw.
Antw.
2486
Views
Views
5
Antw.
Antw.
2805
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
GET_SELETCED_ROWS erkennt im ALV-Grid nach Änderung markierte Zeilen nicht
vor 2 Tagen von sapdepp 6 / 1935
vor 2 Tagen von sapdepp 6 / 1935
Problem: keine Response! wenn die selbe BSP Seite mehrmals aufgerufen!!
vor 5 Tagen von mhsoftware gelöst 9 / 772
vor 5 Tagen von mhsoftware gelöst 9 / 772
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
GET_SELETCED_ROWS erkennt im ALV-Grid nach Änderung markierte Zeilen nicht
vor 2 Tagen von sapdepp 6 / 1935
vor 2 Tagen von sapdepp 6 / 1935
Problem: keine Response! wenn die selbe BSP Seite mehrmals aufgerufen!!
vor 5 Tagen von mhsoftware gelöst 9 / 772
vor 5 Tagen von mhsoftware gelöst 9 / 772