View Full Version : SQL Performance Probleme im Batch
Hallo,
bin gerade am Verzweifeln.
Seit geraumer Zeit laufen diverse SQL's im Batch dramatisch langsamer als interaktiv.
Speziell ein Programm wo mehrfach ein anderes Programm aufruft, welches 2 komplexe SQL's in einer Schleife ausführt.
Ich habe nun für heute Nacht eine Zeitmessung ins Programm eingebaut, wo mir per Timestamp before und after die Dauer ermittelt. Dauer jedes SQL's mind. 5 MINUTEN eher noch mehr. Interaktiv ist das Ergebnis sofort da.
Die SQL's bestehen aus mehreren Joins sowie Union select.
Ich habe die SQL's analysiert (debug und IBM Navigator). Beide male wurden die Indizes gefunden. Der joblog sagt mir dass alle Zugriffswege gefunden wurden.
Es bleibt noch zu sagen, dass in diesem Batch viele Programme laufen und dass das joblog
ca. 30.000 Seiten hat.
Wenn das gleiche Problem tagsüber aufgerufen wird, gibt es keine Probleme. Zugriffsdauer liegt im Millisekunden Bereich.
Der Systemvalue QQRYDEGREE steht auf *OPTIMIZE.
AS/400 Release V7R1M0.
Auf dem Testsystem mit gleichem Releasestand aber nicht so vielen Daten laufen die SQL's in einer Minute durch.
Danke.
... zur Analyse: STRDBMON ist Dein Freund und Fehlermeldung an IBM nicht vergessen, neue Releases sind meist buggy...
D*B
andreaspr@aon.at
26-02-14, 09:21
Meinst du mit Interaktiv STRSQL? Denn dort wird so weit es geht für die Ausgabe der ersten (~20) Sätze optimiert und im Batch werden ja alle Sätze gelesen.
Interessant wäre auch wie die Systemauslastung (CPU und Disk) generell zu diesem Zeitpunkt ist.
Wie schaut zu diesem Zeitpunkt der Systemjob QDBFSTCCOL aus?
Im DB-Monitor vom Navigator solltest du sehen können welche Schritte beim SQL wie lange dauern und wo der Flaschenhals ist.
lg Andreas
OK super, vielen DANK. Ich werde den STRDBMON einbauen, glaube aber nicht, dass es ein SQL Problem ist. Tippe irgendwie auf das System.
Sowohl interaktiv (STRSQL) als auch auf dem Testsystem gibt es keine Probleme, alles passt.
Eine Frage zum STRDBMON. Mit welchen Parametern soll ich den Befehl am Besten aufrufen?
Gruß Klaus
... wenn Du den in den Jobablauf des Batchs reinkriegst, das ist das genaueste; dann mit STRDBMON TYPE(*DETAIL) und outfile und outmbr angeben. Auswertung mit oops nerv. Damit kriegst du zumindest raus, wo genau die Zeit verbruzzelt wird und kannst für die Fehlermeldung ein minimalisiertes Beispiel liefern. Als erstes würde ich allerdings vorab mal den aktuellsten Stand für die Database PTFs reinfeuern.
Wenn Du den STRDBMON von außerhalb machst, dann bleibt fast nur JOB(*ALL) und dann kann es mit der Datenmenge etwas mehr werden, gelinde gesagt.
D*B
PS: der Ooops Nerv direkt bringt Dich nicht weiter, Du brauchst ja genau die Konstellation des Batch Jobs.
Auswertung mit oops nerv.
Danke.
Was ist Ooops Nerv?
Ich kann den STRDBMON direkt ins CL Programm packen, danach wird das SQLRPG aufgerufen.
LG Klaus
Wie oben bereits beschrieben, ist STRSQL generell kein Vergleich zu embedded SQL.
Ich habe auch schon bei STRSQL mit verschiedenen OPTIMIZE-Klauseln gearbeitet, komme aber immer zum selben Ergebnis.
Einen Punkt habe ich aber doch schon mal gefunden.
Auch beim Group By wird versucht über einen Index zu gehen.
da gibt es allerdings Situationen wo das ungünstiger ist, als den Group By im Speicher bzw. auf Datenkopien des Queryoptimizers machen zu lassen.
Um die Indexverwendung eines Group By auszuschließen, reicht ein berechnetes Feld zu verwenden:
select coaleasce(f1, f1) f1, coaleasce(f2, f2) f2, sum(fx) fx
from mytable
where .....
group by coaleasce(f1, f1), coaleasce(f2, f2)
Die Daten werden durch die Whereklausel schnell gefunden, aber der Group By kann keinen Index verwenden.
Dies zwingt den Optimizer ggf. dazu temporäre Ergebnisse zu generieren oder einfach nur den Speicher zu bemühen.
Auch wenn man es kaum glaubt, es machte schon die eine oder andere Abfrage erheblich schneller.
KingofKning
26-02-14, 10:34
Ooops Nerv? = Operations Navigator!GG
Wie oben bereits beschrieben, ist STRSQL generell kein Vergleich zu embedded SQL.
Ich habe auch schon bei STRSQL mit verschiedenen OPTIMIZE-Klauseln gearbeitet, komme aber immer zum selben Ergebnis.
Einen Punkt habe ich aber doch schon mal gefunden.
Auch beim Group By wird versucht über einen Index zu gehen.
da gibt es allerdings Situationen wo das ungünstiger ist, als den Group By im Speicher bzw. auf Datenkopien des Queryoptimizers machen zu lassen.
Um die Indexverwendung eines Group By auszuschließen, reicht ein berechnetes Feld zu verwenden:
select coaleasce(f1, f1) f1, coaleasce(f2, f2) f2, sum(fx) fx
from mytable
where .....
group by coaleasce(f1, f1), coaleasce(f2, f2)
Die Daten werden durch die Whereklausel schnell gefunden, aber der Group By kann keinen Index verwenden.
Dies zwingt den Optimizer ggf. dazu temporäre Ergebnisse zu generieren oder einfach nur den Speicher zu bemühen.
Auch wenn man es kaum glaubt, es machte schon die eine oder andere Abfrage erheblich schneller.
Ggroup by ist drin mit ca. 30 Feldern. Es werden Lieferscheine gruppiert und da sind u.a. die Zahlungsbedingungen dabei, deshalb so viele Felder.
Dies ist das erste Mal wo ich derartige Probleme habe. Wir arbeiten viel mit SQLRPG Programmen und es gab nie Probleme. Wenn mal ein SQL langsam war, dann lag es meistens am fehlenden Index und der fehlte dann auch im STRSQL. So ist es echt schlecht.
Also ein Group By mit 30 Feldern ist schon ungewöhnlich.
Bei SQL's mit vielen Joins ist auch der Optimizer irgendwann überfordert und benötigt eben ewig.
Beschleunigen kann man das Ganze durch Zerlegung in Einzeloperationen.
Damit das Programm aber nicht generell umgeschrieben werden muss, kann man auch mit:
create table xxx1 as select ...
create table xxx2 as select ...
create table xxx3 as select ...
select * from xxx1 join xxx2 ... join xxx3 ...
ein wenig nachhelfen.