SQL Performance

[Allrounder]

Ich habe folgenden Effekt:

Ein RPG-Programm liest in einer Schleife eine Physische Datei
und gibt den Inhalt nach einigen rtrim und diversen Datumsprüfungen mit einem Insert (Embedded) in eine SQL-Tabelle aus.

Das Problem ist nun die Laufzeit. Es sind 11,7 Mio Datensätze, die geschrieben werden. Die ersten 4-5 Millionen Datensätze gehen schnell, hochgerechnete Gesamtlaufzeit ca. 2 Stunden. Dann wird das Schreiben der Datensätze kontinuierlich langsamer, bei 8-9 Mio Datensätzen ist die Geschwindigkeit der Inserts so langsam, dass der Job ganz in die Knie geht. Aus den 2 Stunden werden dann 23(!) Stunden.

Weiß jemand, wo die Zeit verlorengeht oder wie ich am besten herausfinde, wo das Problem ist? Hatte bisher keine großen SQL-Performance-Probleme und habe mich deshalb noch nicht damit auseinandergesetzt.

Die SQL-Tabelle ist eine Standalone-Tabelle, keine Views, keine Verknüpfungen über Foreign Keys. Es gibt einen Primary Key über eine Idenditätsspalte und einen nicht eindeutigen Index über eine weitere Spalte.

[BenderD]

als erstes würde ich hier immer STRDBMON (mit allen Details) empfehlen, um abzuklären, ob das wirklich am INSERT liegt (und nicht am lesen von gelöschten Sätzen). Wenn die Problembeschreibung exakt ist, dann müsste man über die Zeit zunehmende Insert Zeiten sehen. Dann würde ich mal PTF Stand Database verifizieren. Stimmt das mit den Indexen und Constraints wirklich??? der Effekt an sich riecht nach Index Einflüssen.

D*B

Ich habe folgenden Effekt:

Ein RPG-Programm liest in einer Schleife eine Physische Datei
und gibt den Inhalt nach einigen rtrim und diversen Datumsprüfungen mit einem Insert (Embedded) in eine SQL-Tabelle aus.

Das Problem ist nun die Laufzeit. Es sind 11,7 Mio Datensätze, die geschrieben werden. Die ersten 4-5 Millionen Datensätze gehen schnell, hochgerechnete Gesamtlaufzeit ca. 2 Stunden. Dann wird das Schreiben der Datensätze kontinuierlich langsamer, bei 8-9 Mio Datensätzen ist die Geschwindigkeit der Inserts so langsam, dass der Job ganz in die Knie geht. Aus den 2 Stunden werden dann 23(!) Stunden.

Weiß jemand, wo die Zeit verlorengeht oder wie ich am besten herausfinde, wo das Problem ist? Hatte bisher keine großen SQL-Performance-Probleme und habe mich deshalb noch nicht damit auseinandergesetzt.

Die SQL-Tabelle ist eine Standalone-Tabelle, keine Views, keine Verknüpfungen über Foreign Keys. Es gibt einen Primary Key über eine Idenditätsspalte und einen nicht eindeutigen Index über eine weitere Spalte.

[KingofKning]

Die Frage die sich stellt, ist ob Du evtl. die Sätze sortiert einliest und auch genaus so sortiert wegschreibst.
Es gibt nix schlimmeres für einen Index als wenn er sofort sortiert ist. (Zumindestens habe ich das mal vor 15 Jahren so gelernt bei B-Tree und Konsorten).


Gruß
Gregor

[BenderD]

das mag vor 15 Jahren mal gestimmt haben...

Die Frage die sich stellt, ist ob Du evtl. die Sätze sortiert einliest und auch genaus so sortiert wegschreibst.
Es gibt nix schlimmeres für einen Index als wenn er sofort sortiert ist. (Zumindestens habe ich das mal vor 15 Jahren so gelernt bei B-Tree und Konsorten).


Gruß
Gregor

[Allrounder]

Erst einmal vielen Dank. Ich werde den STRDBMON aufsetzen. Entspricht das dem SQL Performance Monitor im iSeries Navigator?

[BenderD]

im OOPs Nerv heißt das Ding in jeder Version anders, dahinter steht dann ein STRDBMON auf der AS/400 (kann man Job bezogen starten - beenden nicht vergessen, immer mit vollen details starten). Auswerten muss man das (leider) mit OOPs Nerv (wenn es denn funktioniert). Das Tool (Database Monitor) ist genial, die Benutzeroberfläche (OOPs Nerv) eine Frechheit!!!

D*B

Erst einmal vielen Dank. Ich werde den STRDBMON aufsetzen. Entspricht das dem SQL Performance Monitor im iSeries Navigator?