DELETE von über 420 Mio. Datensätzen
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Beitrag
von RantanplanFX (ForumUser / 20 / 2 /
0
)
»
Hallo zusammen
ansicht habe ich ne recht simple Frage
Ich möchte eine Datenbanktabelle mit folgenden SQL Statement bereinigen.
"delete from /ihtzr/bgp_fscma where datum < gv_condate"
Der DELETE umfast ca. 420 Mio Datensätze!
Mein erster Versuch hat in einem Systemcrash geendet.
Wie genau muss ich vorgehen, damit es nicht nochmal in solch einem Disaster endet?
Protokollierung abschalten?
Packt die WHERE Bedingung das eigentlich?
Danke schon mal im Voraus für eure Hilfe.
Gruß
André
ansicht habe ich ne recht simple Frage
Ich möchte eine Datenbanktabelle mit folgenden SQL Statement bereinigen.
"delete from /ihtzr/bgp_fscma where datum < gv_condate"
Der DELETE umfast ca. 420 Mio Datensätze!
Mein erster Versuch hat in einem Systemcrash geendet.
Wie genau muss ich vorgehen, damit es nicht nochmal in solch einem Disaster endet?
Protokollierung abschalten?
Packt die WHERE Bedingung das eigentlich?
Danke schon mal im Voraus für eure Hilfe.
Gruß
André
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Schön ist das Vorgehen zwar nicht, aber theoretisch könnte man die dbtab einlesen und dann die zu löschenden Einträge stückchenweise in eine itab übergeben und dann ein DELETE dbtab FROM TABLE itab machen...
Beitrag
von RantanplanFX (ForumUser / 20 / 2 /
0
)
»
Macht es sinn die Protokollierung
auszuschalten? Wennn ja, wie geht das?
auszuschalten? Wennn ja, wie geht das?
Ich denke du musst in Paketen arbeiten, da sonst die DB alles im Puffer hält wegen einem evtl. folgenden ROLLBACK.
hier ein Beispiel:
http://www.abapforum.com/forum/viewtopic.php?t=5843
Gruß
hier ein Beispiel:
http://www.abapforum.com/forum/viewtopic.php?t=5843
Gruß
Moin,
Für DELETE <dbtab> FROM TABLE <itab>.
reicht es eine Interne Tabelle nur mit den Schlüsselfeldern zu benutzen,
um dann mit "select key1 from /ihtzr/bgp_fscma into table itab up to 1000 rows where ...."
zu löschen.
Das macht man, solange der select daten liefert. (Natürlich im Hintergrund)
lg Jens
Für DELETE <dbtab> FROM TABLE <itab>.
reicht es eine Interne Tabelle nur mit den Schlüsselfeldern zu benutzen,
um dann mit "select key1 from /ihtzr/bgp_fscma into table itab up to 1000 rows where ...."
zu löschen.
Das macht man, solange der select daten liefert. (Natürlich im Hintergrund)
lg Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Selbst das wird nicht "fehlerfrei" funktionieren.Tron hat geschrieben:Für DELETE <dbtab> FROM TABLE <itab>.
reicht es eine Interne Tabelle nur mit den Schlüsselfeldern zu benutzen,
um dann mit "select key1 from /ihtzr/bgp_fscma into table itab up to 1000 rows where ...."
zu löschen.
Das macht man, solange der select daten liefert. (Natürlich im Hintergrund)
Es fehlt etwas ganz entscheidendes: COMMIT WORK!
Sonst landen nämlich alle Änderungen in ein und derselben LUW und somit auch im selben Archive-Log.
Noch besser ist es auch zwischen den Schritten etwas abzuwarten (WAIT ... UP TO ... SECONDS) um ganz sicher zu gehen.
lg ADT
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
Hey ADT,
warum nicht
??
Den wait kannst du dir doch damit sparen?
gruss
warum nicht
Code: Alles auswählen.
commit work and waitDen wait kannst du dir doch damit sparen?
gruss
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Das WAIT bei COMMIT WORK wartet auf die Verbucher(!).
Das WAIT UP TO wartet einfach nur.
In meinem Beispiel darauf, dass die Archive-Logs verarbeitet werden können. Die betreffen die Datenbank und werden in SAP/ABAP bei COMMIT nicht berücksichtigt. Da 420 Mio. Datensätze eine ziemliche Menge darstellt sollte man das nicht außer Acht lassen und der Datenbank etwas Zeit gönnen zu "verschnaufen".
lg ADT
Das WAIT UP TO wartet einfach nur.
In meinem Beispiel darauf, dass die Archive-Logs verarbeitet werden können. Die betreffen die Datenbank und werden in SAP/ABAP bei COMMIT nicht berücksichtigt. Da 420 Mio. Datensätze eine ziemliche Menge darstellt sollte man das nicht außer Acht lassen und der Datenbank etwas Zeit gönnen zu "verschnaufen".
lg ADT
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
aber genau das wäre doch sinnvoll.
in einem loop.
delete from where values = ...
commit work and wait.
endloop.
wenn der verbucher fertig meldet, wird der nächst gelöscht.
man kann ja auch nen zähler einbauen, dass er z.b. nach 1000 einträgen einen commit absetzt.
oder?
in einem loop.
delete from where values = ...
commit work and wait.
endloop.
wenn der verbucher fertig meldet, wird der nächst gelöscht.
man kann ja auch nen zähler einbauen, dass er z.b. nach 1000 einträgen einen commit absetzt.
oder?
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Nochmal:
In diesem Fall gibt es keinen im Verbucher registrierten Baustein, ergo auch nichts was "asyncron" verarbeitet werden würde.
Nach sagen wir 1000 Blöcken soll ein COMMIT WORK [AND WAIT] dafür sorgen, dass die Daten auf der Datenbank persitiert werden, ja! DANACH sollte man bei diesen riesigen Datenmengen (420 Mio.) noch warten, sodass die Archive-Logs (fürs Rollback usw.) auf der Datenbank verarbeitet werden können. SAP (COMMIT WORK) wartet hier nicht, da ja die Datenbank das alles schon in den Archive-Logs entgegengenommen hat. Diese werden dann im Anschluss vom Datenbankprozess abgespielt und damit die Daten endgültig festgeschrieben.
lg ADT
In diesem Fall gibt es keinen im Verbucher registrierten Baustein, ergo auch nichts was "asyncron" verarbeitet werden würde.
Nach sagen wir 1000 Blöcken soll ein COMMIT WORK [AND WAIT] dafür sorgen, dass die Daten auf der Datenbank persitiert werden, ja! DANACH sollte man bei diesen riesigen Datenmengen (420 Mio.) noch warten, sodass die Archive-Logs (fürs Rollback usw.) auf der Datenbank verarbeitet werden können. SAP (COMMIT WORK) wartet hier nicht, da ja die Datenbank das alles schon in den Archive-Logs entgegengenommen hat. Diese werden dann im Anschluss vom Datenbankprozess abgespielt und damit die Daten endgültig festgeschrieben.
lg ADT
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
2
Antw.
Antw.
443
Views
Views
Ermittlung von Datensätzen mit bestimmten Status
von kaim77 » 17.03.2022 12:51 • Verfasst in ABAP® Core
von kaim77 » 17.03.2022 12:51 • Verfasst in ABAP® Core
2
Antw.
Antw.
858
Views
Views
Duplizieren von itab-Datensätzen und Ausgabe per ALV + Verbuchung
von kolumbus70 » 10.06.2019 16:35 • Verfasst in ABAP® für Anfänger
von kolumbus70 » 10.06.2019 16:35 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
8038
Views
Views
Fehler: Insert führt zu duplikaten Datensätzen
von Dyrdek » 18.10.2016 14:08 • Verfasst in ABAP® Core
von Dyrdek » 18.10.2016 14:08 • Verfasst in ABAP® Core
1
Antw.
Antw.
1593
Views
Views
Anzahl von Datensätzen aus einer Datenbanktabelle dynamisch lesen
von tekko » 31.03.2022 16:26 • Verfasst in ABAP Objects®
von tekko » 31.03.2022 16:26 • Verfasst in ABAP Objects®
4
Antw.
Antw.
2465
Views
Views
Anzahl von Datensätzen aus einer Datenbanktabelle dynamisch lesen
von tekko » 31.03.2022 16:26 • Verfasst in ABAP Objects®
von tekko » 31.03.2022 16:26 • Verfasst in ABAP Objects®
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 3 Stunden von ralf.wenzel 104 / 9996
vor 3 Stunden von ralf.wenzel 104 / 9996
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 3 Stunden von ralf.wenzel 104 / 9996
vor 3 Stunden von ralf.wenzel 104 / 9996