Massendaten Löschen per RPG delete Tunning

[oulbrich]

Hallo zusammen,

ich habe eind Datei mit ca. 110 Mio Datensätzen. Aus dieser Datei lösche ich per RPG delete ca. 40.000 Datensätze. Das Löschen erfolgt über eine LF mit Key Firma Kundennummer. Das Löschen dauert bis zu 400 Sekunden. Gibt es Einstellungen an der Datenbank oder am System und das zu beschleunigen.

Die Datei ist nicht im Journal aufgeszeichnet und besitzt keine Trigger

[Fuerchau]

Ein Delete ist die langsamste Operation überhaupt.
Der Delete erfolgt nun mal auf der Pf.
Zusätzlich müssen alle abhängigen LF's natürlich mit geändert werden.
Zusätzlich werden die gelöschten Sätze miteinander verkettet.
100 Deletes/Sekunde sind da nicht schlecht.

Performanter geht es nur mit Reduzierung der LF's.
Bei größeren Datenmengen kann man bei den anderen LF's per CHGLF die Maintenance auf verzögert setzen.
Ggf. dauert dann die Maintenance anschließend halt etwas länger, was in der Gesamtbetrachtung dann doch wieder zum selben Ergebnis führen kann.

Hat mal die Parallel-Features der DB gekauft kann man hier noch mal ein wenig gewinnen.

Ggf. kann man auch mit SQL etwas beschleunigen.

[BenderD]

Hat mal die Parallel-Features der DB gekauft kann man hier noch mal ein wenig gewinnen.

Ggf. kann man auch mit SQL etwas beschleunigen.

... das parallel database feature hilft bei Record Löffel Ekzem (RPG delete) nix.
Ein Bulk SQL Statement (delete from ... where...) ist bei 400.000 Sätzen in einer Operation immer einen Versuch wert, ob's was bringt? Versuch macht kluch!

D*B

[oulbrich]

Mit SQL dauert es genau so lange.
Wie sieht es mit Update aus.
Wenn ich ein Statusflag z.B L=gelöscht setzen würde und dann über eine LF mit einem Select die Daten aussortieren würde? Bring das was?

[oulbrich]

Noch ne Frage. Spielt die Anzahl/Größe der LF an der PF bei Löschen eine Rolle?

[BenderD]

... der update auf ein Flag sollte signifikant schneller sein, da ja dabei weniger Indexe tangiert sind. Fügst Du das Flag dann allerdings in Deinen ganzen LFs hinzu, frisst Dir das wieder Zeit. Im übrigen sind die 100 pro Sekunde Grotten schlecht!!! Wenn Du kein antikes Blech und keine Engpässe hast und keine 276 Index Dateien, sollte da eher das 10 fache bei rauskommen...

D*B

[oulbrich]

@BenderD . Das mit dem grottenschlecht meine ich auch, aber alles was ich bis jetzt versucht habe bringt nichts.
IBM i 520 8203-E4A 15GB HSP sollte meiner Meinung nach reichen.
14 LF´s auf der PF. Platten 1,2 TB bei 62 % Auslastung.

Kann ich über den Performancemonitor irgenedwelchen Enpässen sehen.

[Fuerchau]

Da du ja die Daten selektierst, die du löschen willst, ist ggf. gar nicht der Delete das Problem.
In RPG kannst du einen Delete ohne Key durchführen, wenn du den Satz gelesen hast.
Beim Delete mit Key muss der Satz erst neu ermittelt werden.

SQL-Delete verwendet die erste Methode.
Die Anzahl der LF's und die Anzahl der Schlüsselfelder je LF spielen schon eine Rolle.
Auch wenn LF's mit Select/Omit vorhanden sind, macht das System ja mehr.

Wenn die Tabelle auf REUSEDLT(*NO) steht, dauert die Löschverwaltung etwas länger da ja ggf. die zu löschenden Sätze weit gestreut sein können und vor allem das Anfügen (Insert) immer am Ende passiert.

LF's mit langen Schlüsseln dauern auch länger als mit kurzen.
Hier können ggf. SQL-Indizes helfen.

[BenderD]

Kann ich über den Performancemonitor irgenedwelchen Enpässen sehen.

... wer kann, der kann - wenn welche da sind. Ferndiagnosen sind da allerdings immer etwas problematisch. Platte ist nicht gleich Platte, Hauptspeicher hängt von Pools und was darin los ist ab, Index ist nicht gleich Index, ist das ein isoliertes Problem, oder ist alles so langsam, ist das reproduzierbar, oder tritt nur manchmal auf...

D*B

[Fuerchau]

Ist Rätselraten hier im Forum nicht unsere Haupttätigkeit ?

[TheDevil]

Hallo.

Evtl. mal den Parameter FRCRATIO auf der PF prüfen. Wenn der z. B. auf 1 steht dann geht die Performace aber so was von in die Knie (vor allem bei vielen LF Files) ... ich habe das mal bei eineer "Löschaktion" vor einem Releasewechsel einer Warenwirtschaft live miterlebt. Dort konnte man fast jeden einzelnen Datensatz "verschwinden" sehen. Wir haben dann den Paramter vor dem löschen auf *NOMAX gesetzt, die LF gelöscht und dann rannte der Job als ob es kein Morgen mehr geben würde. Das mit den LF löschen würde ich aber in Deinem Fall lassen da Du diese dann ja nach jedem löschen wiederherstellen müsstest was ewit dauern würde ...

Gruß aus dem hohen Norden,
Ralf

[andreaspr@aon.at]

Du könntest auch den System-Job QDBFSTCCOL beobachten ob zum Zeitpunkt deines DELETEs der Statistik-Manager mit dieser Tabelle beschäftigt.
Ist zwar eher unwahrscheinlich, hab ich aber auch schon gehabt!
Bei Tabellen mit vielen Mio Sätzen und einem blöden Statistikeintrag kann dieser Job bis zu über 50 % der CPU verbrauchen!

lg Andreas