SQL Performance Probleme im Batch

[itec01]

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

[BenderD]

... 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.

[itec01]

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

[KingofKning]

Ooops Nerv? = Operations Navigator!GG

[Fuerchau]

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.

[itec01]

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.

[Fuerchau]

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.

[BenderD]

... zuerst muss man wissen was die Query Engine da so treibt, deshalb der STRDBMON, der protokolliert das mit *DETAIL raus (kostet < 1% Laufzeit, aber ziemlich viel Platten Platz). Diese Messung sollte man im Echtbetrieb mitlaufen lassen. Dann startet man den seefahrenden Chirurgen (Operations Navigator, oder wie das Teil gerade mal heißt) da gibt es einen Database Dingensbumens; da muss man dann die Messdaten importieren und sieht sich dann die Einzelstatement Ebene (absteigend sortiert nach Laufzeit) an. Wenn man ein wenig vertraut damit ist, findet man auch Informationen über Zugriffsplan: Interaktiv schnell und Batch langsam sieht nach full table scan, oder irgendwas anderem raffinierten aus, da hilft dann oft ein passender order by für die Ergebnismenge.

Bei großen Datenmengen (ein paar hundert Millionen) ist es im Batch oft vorteilhaft, zuerst temporäre Extracte zu ziehen, die man dann weiter verarbeitet, wenn die Anwendungslogik das zulässt.

D*B

[itec01]

So ich habe Neuigkeiten, die mich noch mehr verzweifeln lassen.
Ich konnte das Problem lokalisieren und habe folgendes gemacht: Das Programm wo nachts läuft habe ich jetzt aufgerufen und siehe da, das SQL dauert.
Ich hatte geschrieben, dass es am Tag schnell läuft, bezieht sich aber auf andere Parameter, sorry.
Script Auszug:
c/exec sql
c+ prepare s1 from :W@SqlStr
c/end-exec
**
c/EXEC SQL
c+ DECLARE CRS1SQL CURSOR FOR S1
c/END-EXEC
**
**
c/EXEC SQL
c+ OPEN CRS1SQL
c/END-EXEC
**
**EXEC SQL
** WHENEVER NOT FOUND GOTO SbSQLEnd
**END-EXEC
c do *hival
c/EXEC SQL
c+ FETCH NEXT FROM CRS1SQL INTO :INPSQL
c/END-EXEC
**
c
**
c if SqlCod < *zero or SqlCod = 100
c leave
c endif

Das Programm bleibt auf den END-EXEC nach dem FETCH ca, 10 Minuten stehen und zieht CPU. Im wrkactjob steht der Job auf RUN und keine IO Operation in der DB.

Habe den STRDBMON aufgesetzt und der sagt, dass alles gut ist. Bevor das Programm stehen blieb waren 54 Sätze in der outfile und danach auch, d.h. der letzte Eintrag war schon vorher da. Da steht auch Start-Time und End-Time. Nur was macht er solange.
Im debug steht, dass alle Indizes genommen wurden.

Gruß Klaus

[B.Hauser]

Wo bleibt er stehen?
Nach dem FETCH oder nach dem OPEN?

Ich schätze mal, nach dem OPEN, d.h. das Öffnen des ODPs dauert sehr lange.
Auch wenn Zugriffswege verwendet werden, heißt das noch lange nicht, dass die korrekten Zugriffswege auch vorhanden sind.
M.E. werden temporäre Zugriffswege/Indices benötigt und erstellt. Das würde die lange Laufzeit und dass CPU ohne Ende gezogen wird erklären. Nachdem die/die temporären Indices erstellt sind, sollte die Verarbeitung sehr schnell erfolgen.
Zunächst sollte geprüft werden, ob und wenn ja welche (temporären) Indices erstellt werden müssen. Diese Zugriffswege sollten dann als permanente Zugriffswege/Indices erstellt werden.
Nachdem die Erstellung der temporären Indices wohl jedes Mal (also in jedem Job) in dem die Abfragen ausgeführt werden durchgeführt werden, ist davon auszugehen, dass die alte/classic Query Engine die Abragen ausführt.
Bevor Indices angelegt werden, sollte versucht werden die Abfragen durch die SQE ausführen zu lassen und anschließend neu zu analysieren.

Muss die Abfrage wirklich dynamisch zusammengesetzt werden?
Das macht die Analyse ziemlich schwierig, da das exakte SQL-Statement zunächst herausgepullt werden muss.

Allerdings ohne die SQL-Statements und die Ergebnisse aus dem Database Monitor zu kennen, kann an dieser Stelle nur geraten werden.

Der Database Monitor kann auch über den IBM i Navigator gestartet werden (über SQL Performance Monitor). Über den IBM i Navigator können die gesicherten Informationen aus dem Performance Monitor ausgewertet werden.

Birgitta

[itec01]

Hallo Brigitta,
habe ich mich so undeutlich ausgedrückt?, sorry! Der Cursor bleibt bei dem END-EXEC nach dem Fetch stehen. Der DBMONITOR zeigt mir als Ergebnis eine Antwortzeit von 100 ms. Wie schon geschrieben, in der Outfile vom DBMONITOR stehen 54 Datensätze und alle sind im ms Bereich.
Ich habe nun einen TRCJOB gemacht. Die Zeit wird verbraten im PGM/Modul QDBGETMQ0.

[Robi]

Das Programm bleibt auf den END-EXEC nach dem FETCH ca, 10 Minuten stehen und zieht CPU. Im wrkactjob steht der Job auf RUN und keine IO Operation in der DB.

hast du mit f15 auf die sqlsicht umgeschaltet?