(Embedded) SQL Problem

[harkne]

Naja, dann habe ich wohl den falschen Ansatz gehabt. Ich dachte der SENSITVE SCROLL Cursor wird gebraucht, damit er nicht die komplette Datenmenge einliest, sondern immer nur soviel liest wie er braucht. Mit STRDBG habe ich bereits gesehen welchen und dass er einen Index verwendet. Wir haben nur festgestellt das die Problemtatik überwiegend beim embedded SQL vorkommt. Ich hab das SQL über Client Access ausgeführt und er hat noch nicht mal mit der Wimper gezuckt um mir die 3 Datensätze anzuzeigen. Mit dem Sensitive Scroll Cursor 9 Minuten !!! und mit STRSQL auch noch 30 Sekunden. Ohne den Sensitive Scroll Cursor braucht er jetzt noch 30 Sekunden. @Bender ... wenn Du dir das SQL-Statement angeschaut hast, dachte ich zunächst, dass das IN das Problem ist, durch die Komplexität dahinter, lass ich das weg wirds aber auch nicht schneller. Höchstwahrscheinlich liegt es am Join auf die DNPTRNP mit mehreren Feldern gemischt. Als ich das Sensitive Cursor weggelassen hatte war dann zwar dieses SQL-Statement schneller (nur noch 30 Sekunden) was mir persönlich immer noch zu lange dauert, allerdings wenn jemand dann nur den DIST auswählt braucht er ohne Sensitive Scroll viel länger als mit Sensitive Scroll. Ich hab das jetzt so angepasst, dass er, wenn er was eingibt, bei dem ich wenig Datensätze erwarte ohne Sensitive Scroll arbeitet und wenn ich viel Datensätze erwarte mit Sensitive Scroll. Somit ist alles "erträglich" aber weit weg von zufriendenstellend.

Vielen Dank für Eure Hilfe

[BenderD]

Mit STRDBG habe ich bereits gesehen welchen und dass er einen Index verwendet.


@Bender ... wenn Du dir das SQL-Statement angeschaut hast, dachte ich zunächst, dass das IN das Problem ist, durch die Komplexität dahinter, lass ich das weg wirds aber auch nicht schneller. Vielen Dank für Eure Hilfe

... wenn ein SQL Statement einigermaßen lesbar sein soll, dann sollte man für alle Tabellen einen kurzen alias (A, B, C oder T1 T2 T3) vergeben und alle Felder mit Herkunft prefixen, dann bräuchte man auch noch die Felddefinitionen und wäre immer noch nicht viel schlauer.

Die wesentliche Arbeit musst Du schon selber machen. Mag sein, dass da irgendwo, irgendwie ein Index genommen wird, spannend ist doch die Frage, was da unterschiedliches passiert. Dazu muss man halt beide Varianten unter Debug laufen lassen und dann die Joblogs vergleichen, wo der Unterschied liegt. Wenn da alpha Felder für join oder order by im Spiel sind, reicht da evt. schon eine andere CCSID Einstellung im Job - das kann man aus der Ferne nicht sehen.

D*B

[harkne]

Ich wollte auch nicht, dass mir jemand die Arbeit abnimmt. Meine ursprüngliche Frage lief darauf hinaus, dass ich nicht verstehen konnte warum über Client Access das ganze rasend schnell zu einem Ergebnis kommt und der STRSQL auf der AS400 bzw. das embedded SQL so lange braucht. Ich dachte dass es da ein bekanntes Problem oder ähnliches gibt. Das SQL wollte ich ursprünglich gar nicht posten, ich dachte nur dass jemandem vielleicht was auffällt und er/sie sagt, ja bei der oder der Art der Verknüpfung hat die AS/400 Probleme über Client Access geht es deshalb schneller weil ...
Wenn es dazu keine Antwort gibt, bin ich auch damit zufrieden, dann darf ich es vielleicht wieder mit einem altbackenen READE programmieren was aus meiner Sicht in bestimmten Fällen einfach die schnellere Lösung ist.

[BenderD]

... es gibt immer eine Antwort und die ist in diesem speziellen Fall unmittelbar aus den beiden Joblogs ersichtlich. Wie Du dieses SQL Statement mit einem "altbackenen READE" ablösen willst, das ist mir ein wenig schleierhaft, aber sei#s drum.
Was Dein SQL Statement angeht, ein where KONSTANTE in (select ...), das ließe sich auch in einen inner join auflösen, der nur das mitnimmt, was mit der KONSTANTE matched.

D*B

[B.Hauser]

... es gibt immer eine Antwort und die ist in diesem speziellen Fall unmittelbar aus den beiden Joblogs ersichtlich. Wie Du dieses SQL Statement mit einem "altbackenen READE" ablösen willst, das ist mir ein wenig schleierhaft, aber sei#s drum.
Was Dein SQL Statement angeht, ein where KONSTANTE in (select ...), das ließe sich auch in einen inner join auflösen, der nur das mitnimmt, was mit der KONSTANTE matched.
D*B

Passiert zwar selten, aber zur Abwechslung bin ich mal mit Dieter einer Meinung.

I.d.R. performen Inner-Joins (mit und ohne Sub-Select oder CTE) besser als Sub-Selects in WHERE-Bedigungen. Der Query Optimizer kann nämlich in diesen Fällen ggf. die Reihnfolge der Verknüpfungen ändern. Bei Sub-Selects in den WHERE-Bedinungen zwingt man dem Optimizer die Reihenfolge auf.
In Deinem Beispiel kommt noch erschwerend dazu, dass der Sub-Select mit einer Konstanten vergleicht. Damit nimmt man dem Optimizer auch noch die Möglichkeit einen Index zu verwenden.

Führe ich das mit einer 5250 Emulation über Client Access aus, habe ich das Ergebnis in 4-5 Sekunden. Rätsel über Rätsel

Versuch noch mal eines: Füge in Deinem Cursor am Ende des SELECT statements mal folgendes ein:
OPTIMIZE FOR 10 ROWS.

Wenn Client Access schnell ist und embedded SQL langsam, so liegt das meist am Optimierungsziel. Dynamische SQLs (u.a. auch STRSQL oder Client Access) werden mit Optimierungsziel *FIRSTIO optimiert, während statisches SQL mit *ALLIO optimiert wird.
Das heißt, dass bei *FIRSTIO im Zweifel noch ein Index verwendet wird, während bei *ALLIO im Zweifel eine Table Scan ausgeführt wird.
Normalerweise ist die Sachlage eindeutig, aber in bestimmten Situationen (in die Du u.U. gerade gestolpert bist), kann das beträchtliche Auswirkungen haben.
Mit OPTIMIZER FOR x ROW kann das Optimierungsziel beinflusst werden, d.h. x=kleine Zahl --> *FIRSTIO, x=große Zahl oder ALL --> *ALLIO

Birgitta

[harkne]

Vielen Dank für die Hilfe an alle

[Fuerchau]

Also das OPTIMIZE FOR x ROWS habe ich auch schon des öfteren ausprobiert. Konte damit aber absolut keine unterschiedliche Reaktion auslösen. STRSQL blieb immer schneller als später das embedded SQL.
Auch beim OperationsNavigator konnte ich damit keinen Einfluss gewinnen, wobei dieser sich dem embedded SQL eher annäherte.
Ich denke mal, STRSQL verwendet das SQL-CLI und da hat man sicherlich noch ein paar Stellschrauben per Attributsteuerung als in der normalen Verbindung.

Inzwischen habe ich es aufgegeben an dieser Stellschraube zu drehen sondern eher über indizes oder statt eines " xxx in (select ....)" einen " exists (select ....)" zu verwenden da dieser tatsächlich bei vorhandenem Index schneller ist.