SQL Select Statement - Execute dauert sehr lange

[Robi]

Recourcenengpässe sind es M.e. nicht denn...
hier nicht erwähnt wurde ...

1.) Wenn ich genau das SQL -Statement aus dem LOG kopiere und in einer grünen Sitzung ausführe,
habe ich (je Statement) nach maximal 9 Sekunden mein Ergebnis

2.) Die Laufzeit scheint vom Wetter / Tagesform / ... ab zu hängen. Es gibt Tage, da ist die gesamte Statistik nach 1,5-2 Minuten durch, andere Tage (Heute!) läuft das mehrere Stunden!
Die Auslastung der AS400 ist immer gleich, da gibt es keine Lastspitzen durch irgendwelche großen Läufe. CPU immer so bei 35-39 %

@DB kannst du das bitte übersetzen

ich würde auch einen ordentlichen ConnectionPool nehmen und nicht diesen Dollschachtel Kram

Danke
Robi (der gerade wieder testet, da nun alle PTF eingespielt sind)

[Fuerchau]

Ich würde da schon auf ein massives Indexproblem tippen.
QDBGETMQO deutet auf eine MaterializedQuery-Table hin.
M.a.W., ier wird ein Tablescan durchgeführt der eine temporäre MQ-Table erstellt. Diese sind nach IPL meist wieder weg.
Außerdem ist es immer wieder faszinierend, wie SQL ganz anders bei STRSQL optimiert als bei embedded oder ODBC/JDBC. Alle QAQQINI-Einstellungen haben bei mir noch nie zu einer gleichartigen Optimierung geführt.

Deshalb (bei Java kenne ich die Option nicht) nochmal:
Du musst mal die DEBUG-Nachrichten aktivieren und die Joblog-Nachrichten prüfen.

Zur Not kannst du die SQL's auch mal per Opsnav ausführen.
Hier kannst du dir, nach Einschalten, die Diagnosenachrichten direkt ansehen.
Wenn das nicht klappt, versuche es mal mit Excel und Import via ODBC-Quelle.
Hier kannst du den Debugmodus in ODBC konfigurieren.

Beim Debugmodus sollte mehr als "Der Zugriffsplan wurde neu erstellt" stehen.

[BenderD]

Recourcenengpässe sind es M.e. nicht denn...
hier nicht erwähnt wurde ...

1.) Wenn ich genau das SQL -Statement aus dem LOG kopiere und in einer grünen Sitzung ausführe,
habe ich (je Statement) nach maximal 9 Sekunden mein Ergebnis

2.) Die Laufzeit scheint vom Wetter / Tagesform / ... ab zu hängen. Es gibt Tage, da ist die gesamte Statistik nach 1,5-2 Minuten durch, andere Tage (Heute!) läuft das mehrere Stunden!
Die Auslastung der AS400 ist immer gleich, da gibt es keine Lastspitzen durch irgendwelche großen Läufe. CPU immer so bei 35-39 %

@DB kannst du das bitte übersetzen

Danke
Robi (der gerade wieder testet, da nun alle PTF eingespielt sind)

... der grüne macht meist optimize for 1 row (oder wenige), das kann bei optimize for all anders aussehen (da werden full table scans eher favorisiert).

Die wechselnden Zugriffszeiten sind geradezu typisch für einen schlechten Connection Pool. Wenn das statemet und temp. indexe in einer Connection gecached sind, dann funzt es, fängt er bei nix an, dann dauert es. (Dollschachtel wie Toolbox) Bessere Pools machen prepared statements und geben Dir diesselbe Connection, wenn es geht, für dasselbe Statement.

Den Debug kannst Du per Connection Property setzen.

Dennoch bleibt es dabei, dass hier was am Index Design krumm ist. Auf einem anderen Blatt steht, ob man durch ziehen von Extrakten, bzw. mit mehr Redundanz im Datenbankdesign hier was machen kann/muss - das ist aber alles eh Kaffeesatz, wenn die Infos nur homöopatisch verabreicht werden.

D*B

[Robi]

Ganz ehrlich?
Ich raff es nicht!
Die Kiste fährt jede Nacht runter!
Wir haben eben den Debug wieder eingeschaltet (ging vorher nie, da die Berechtigung für strtrc fehlte)
Aufgerufen, 21,22,23 fertig (so wie's sein soll)
Den QZDASOINIT Job hab ich beim 2 versuch grad noch so erwischt, aber da steht nix im Joblog, ein Spool hängt da auch nicht dran.
Das Log, das der Java Job geschrieben hat ist riesig, sagt uns aber nix. Ok, heute ist es mal wieder schnell gewesen.
Zu den Daten:
Wir erstellen eine View über 5 Dateien, die Verknüpfung ist immer der unique key, hier meist als indexiertes PF.
Diese View wird mit einer 2. View nach Mandant selektiert (immer 1 Mandant) und nach Monat/Jahr Summiert und ausgegeben 12 Sätze eines SQL's + 3 (Konstante) Kopf Sätze die separat, NICHT aus der View selektiert werden.
Die View's werden nach dem Aufruf des letzten Mandanten gelöscht ( Statistik, wird nur ein mal / Monat gebraucht)

also : select '31.01.2015', '17.02.2015', '31.01.2015' from sysibm/sysdummy1
dann select feld1, feld2, ...from view2 where Mandant = m_Nr and jjmm between 201101 and 201112
dann select feld1, feld2, ...from view2 where Mandant = m_Nr and jjmm between 201201 and 201212
... 2013,14,15

(die between Daten sind variablen, das ist also eine Schleife)
Der Block (andere Felder im select) 3 mal, fertig

Heute morgen: mehrfach aufgerufen, so schnell wie es sein soll,
Gesten nachmittag, quälend langsam (fast 2 Stunden)

[Fuerchau]

Das deutet auf einen IPL am Wochenende hin, so dass temporäre, aber gemerkte Indizes dann wieder weg sind.
Das Löschen eine View ist eigentlich unnötig, sie kostet nichts.
Das Problem sind ggf. nicht die Verknüpfungen sondern die Where-Bedingung.
Hier entscheidet die AS/400 den Indexaufbau bzw. Tablescan.

Um den Debug einzuschalten benötigst du Berechtigung an STRDBG und nicht an STRTRC.
Also muss deine Einstellung für Debug in der Connection noch falsch sein, das deutet auch auf die Menge an Joblog-Einträgen hin.

[Robi]

? IPL am Wochenende?
äh, ja, nicht nur das. Ich schrieb:

Die Kiste fährt jede Nacht runter!

Das sollte bedeuten: jeden Tag IPL

Hmm,
unser erster versuch mit Debug brachte im Joblog die Meldung, das die Berechtigung für strtrc fehlt.
Ich frag nochmal in der Java Abteilung
Danke
Robi

[Robi]

So, nun mit debug ...

einzig diese Meldung könnte auf ein Prob. hin deuten:

Nachrichten-ID . . . . : CPI4338 Bewertung . . . . . . : 00
Nachrichtenart . . . . : Information
Sendedatum . . . . . . : 18.02.15 Sendezeit . . . . . . : 11:23:16

Nachricht . . . : 1 Zugriffspfad(e) für die Bitmap-Verarbeitung von Datei
FMD_STAT1 verwendet.
Ursache . . . . : Bitmap-Verarbeitung wurde für den Zugriff auf Sätze aus
Teildatei FMD_STAT1 der Datei FMD_STAT1 in Bibliothek BECKERF0 verwendet.
Bitmap-Verarbeitung ist eine Methode, bei der für den Zugriff auf
ausgewählte Sätze in einer Datei ein oder mehrere Zugriffspfade verwendet
werden können. Bei Bitmap-Verarbeitung wird zum Erstellen einer Bitmap die
Satzauswahl an jedem Zugriffspfad angelegt, ähnlich der
Schlüsselspaltenpositionierung. In der Bitmap sind nur die Sätze der Datei
markiert, die ausgewählt werden sollen. Wird mehr als ein Zugriffspfad
verwendet, werden die resultierenden Bitmaps mit Hilfe Boolscher Logik
gemischt. Die resultierende Bitmap wird verwendet, um den Zugriff nur auf
Weitere ...

die aus der Datei ausgewählten Sätze zu beschränken.
Bitmap-Verarbeitung wird gemeinsam mit zwei primären Zugriffsmethoden
verwendet: Zugriffsmethode nach Eingangsfolge (CPI4327 oder CPI4329) oder
Zugriffsmethode nach Schlüsselfolge (CPI4326 oder CPI4328). Die Nachricht
mit einer Beschreibung der primären Zugriffsmethode ist dieser Nachricht
vorangestellt.
Wird die Bitmap mit der Zugriffsmethode nach Schlüsselfolge verwendet,
dient die Bitmap zur Reduzierung der Anzahl der vom primären Zugriffspfad
ausgewählten Sätze, bevor die ausgewählten Sätze aus der Datei abgerufen
werden.
Wird die Bitmap mit der Zugriffmethode nach Eingangsfolge verwendet,
können bei der sequenziellen Suche in der Datei alle nicht von der Bitmap
ausgewählten Sätze der Datei übersprungen werden. Dieses ist auch als
sequenzielle Verarbeitung mit Überspringen (Skip Sequential Processing)
bekannt.
Die im folgenden aufgeführte Liste zeigt die Namen der Zugriffspfade, die
in der Bitmap-Verarbeitung verwendet werden:
TESTF/AKTENL11
Falls es sich bei Datei FMD_STAT1 in Bibliothek BECKERF0 um eine logische
Datei handelt, ist Teildatei AKTENP der physischen Datei AKTENP in
Bibliothek TESTF die eigentliche Datei, auf die zugegriffen wird.
Fehlerbeseitigung: Die Themensammlung "DB2 for i - Database Performance and
Query Optimization" der Kategorie Datenbank im IBM i Information Center
enthält weitere Hinweise zur Bitmap-Verarbeitung.

Die anderen Nachrichten, die einen Zugriffspfad empfehlen beziehen sich auf sehr kleine Dateien mit 30-40 Sätzen, die überwiegend der Textung einzelner Kennzeichen dienen.

Und eine Datei, deren Key key1 und key2 ist. Die Empfehlung lautet key2 und key1!
Diese Datei ist IMMER mit beiden Feldern verknüpft, eine Where Bedingung ist nicht auf diese Keyfelder vorhanden.

Wenn es das nächste mal 2 Stunden läuft leg ich die mal an

Ist schon komisch ...
Jetzt geht es gerade wie es soll und man hofft das es wieder langsam wird ...

Robi

[Fuerchau]

Der Optimizer ist schon manchmal eine Katastrophe!
Bei einer Verknüpfung baut dieser die Reihenfolge der Joins schon mal um.
Beispiel:
Aus
select * from filea a
inner join fileb b on a.key=b.key
wird dann gerne
select * from fileb b
inner join filea a on a.key = b.key

Je nach Satzanzahl und Auswahl ist der umgedrehte Weg aber ungünstiger da ggf. erheblich mehr Daten gelesen werden müssen.
Wenn schon umgedreht, kann man ggf. Bedingungen der Where-Klauses in die Join-Klausel legen und einen Index drüber legen, z.B.:

select *
from filea a
inner join fileb b on a.key = b.key

where b.F1 = 'Wert1'
and a.f2 = 'Wert2'

Where-Klauseln aus 2 (oder mehr Dateien) sind eher selten per Index auswählbar da immer beide Seiten verarbeitet werden müssen.
Hier bietet sich das Anhängen von teilen der Where-Klauseln an die Joinbeziehung an sowie Anlegen des entsprechenden Indexes:

select *
from filea a
inner join fileb b on b.F1 = 'Wert1' and a.key = b.key
where b.F1 = 'Wert1'
and a.f2 = 'Wert2'

oder je nach Volumen der beteiligten Dateien die Abfrage umzudrehen und den Index zu erstellen:

select *
from fileb b
inner join filea a on a.F2 = 'Wert2' and a.key = b.key

where b.F1 = 'Wert1'
and a.f2 = 'Wert2'

Ziel ist es einfach, die Anzahl der benötigten Lesezugriffe zu minimieren.
Auch hier hat sich für mich gezeigt, dass der Optimizer leider das Umdrehen selber übernimmt und dadurch ungünstiger wird.
Hier hilft das gezielt Einsetzen von "Left Join" und das Abfragen im Where per Coalesce, da der Optimizer ja sonst automatisch wieder einen "Inner Join" daraus strikt.

select *
from filea a
left join fileb b on b.F1 = 'Wert1' and a.key = b.key
where coalesce(b.F1, '') = 'Wert1'
and a.f2 = 'Wert2'

Der Optimizer will schon mal überlistet werden.

[Robi]

Moin zusammen,

Gestern ist der Aufruf (ohne Änderungen) vom Admin nach 1,5 Stunden abgebrochen worden, da es das System gebremst hat.
Ich hatte, parallel zu dem Lauf, ein paar LF gemäß Debug Empfehlung angelegt
(obwohl ich nicht wirklich einsehe auf Dateien mit max. 50 Sätzen zusätzliche LF zu legen)
Der 2. Aufruf (mit den LF) war dann wieder schnell.
Heute morgen läuft er wieder endlos, die LF Empfehlungen sind andere.
Vorgestern war (den ganzen Tag, auch der 1. Aufruf) alles schnell, nun ist es wieder 'mal so, mal so'
Wenn immer der 2 Aufruf schneller ging, ok aber selbst das ist nicht (immer) so.

Habe die View Erstellung und das letzte Posting von Baldur nun an 2 Kollegen gegeben.
Vielleicht können die noch was verschlimbessern!

Danke allen die uns unterstützt haben.
Robi

[Robi]

Nachtrag:
durch den eingeschalteten DEBUG kommt ein Spool raus : JOBSQL
In dem steht, nach jedem aufgelisteten SQL-Statement:

SQL4021 Zugriffsplan zuletzt am 19.02.15 um 15:48:46 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 0 Sekunden.
....
...das nächste Statement
SQL4021 Zugriffsplan zuletzt am 19.02.15 um 16:15:38 gesichert.
SQL4020 Geschätzte Abfrageausführungszeit beträgt 0 Sekunden.


Bleibe dabei ... am Zugriff kann es nicht liegen
Robi

[Fuerchau]

Dann würde ich dir eine Fehlermeldung an IBM empfehlen.

[Fuerchau]

Ich kann da so manche bzgl. des Optimizers schon verstehen.
Seit V7R1 laufen da halt viele SQL's langsamer.
Ich habe nun eine QAQQINI-Option ausgeschaltet:

FORCE_JOIN_ORDER *YES

Damit verhindere ich das Umbauen der Joins durch den Optimizer. Schließlcih habe ich mir bei den Joins und den On-Beziehungen was gedacht und entsprechende Indizes angelegt.
Und siehe da:
Ein SQL der mit V6R1 noch schnell war, mit V7R1 sporadisch, also wie oben nicht immer, 30 Minuten brauchte, läuft nun immer unter 1 Minute (Gesamtverarbeitung, nicht nur die Abfrage selber).
Na wer sagt's denn!!!!