DEBUG - Abgesetzten SQL herausfinden

[mojo]

Hallo *ALL,

immer wieder habe ich das Problem (speziell bei komplexen SQLs mit CASE), dass ich beim Debugging gerne den abgesetzten SQL sehen würde.
Klar kann ich mir den SQL in ein Skript kopieren und die CASEs durch die entsprechenden Werte (wie im Debugger ausgelesen) ersetzen.
Das ist aber sehr aufwändig, fehleranfällig und bei jeder Ausführung dann doch wieder anders.

Hat jemand einen Tipp wie ich an den ausgeführten SQL ran komme?

Und wenn wir grade beim Thema rausfinden sind:
Hat vielleicht jemand eine Idee ob und wenn ja wie der Inhalt eines Cursors eingesehen werden kann?

Vielen Dank im Voraus für eure Ideen!

VG! mojo

[B.Hauser]

Jedes SQL Statement, das mit der SQE ausgeführt wird, wird im SQE Plan Cache gespeichert.
Der iSeries Navigator liefert Tools mit denen man den Plan Cache (Datenbank --> SQL Plan Cache --> Rechtsklick/Kontext Menü --> Show Statements) filtern kann.

Zur Analyse (Rechtsklick auf das gewünsche SQL Statement) hat man u.a. auch die Option "Work With SQL Statement and Variables" über die man sich das komplette SQL Statement incl. der eingesetzten Variablen-Werte als Skript anzeigen (ändern und testen) kann.

Ansonsten ist mein Tipp:
Anstatt komplexe SQL-Statements (statisch oder dynamisch egal) direkt im Quell-Code zu hinterlegen, prüfe ob nicht ein Großteil dieses Statements in einer View hinterlegt werden kann, so dass sich das Statement auf SELECT Fld1, Fld2, ... FldX From View mit ein paar zusätzlichen WHERE-Bedingungen und ORDER BY-Anweisungen reduziert.

Da eine View keinen Schlüssel hat (bzw. alles was im SELECT möglich ist außer ORDER BY enthalten kann), kannst Du buchstäblich Tausende von Views auf der Maschine haben, ohne irgendwelche Performance-Einbußen befürchten zu müssen.

Birgitta

[mojo]

Hallo Birgitta und Danke für die schnelle Antwort!

in den Anweisungen des SQL-Plancaches sehe ich aber leider auch nicht das tatsächlich ausgeführte SQL, sondern nur das SQL mit den CASEs und Variablen.
Oder gibts hier noch irgend nen Trick den ich nicht kenne?

Grüße,
mojo

[BenderD]

Oder gibts hier noch irgend nen Trick den ich nicht kenne?

Allerdings! Keep it simple!
Statt vermeintlichen Zaubereien mit Käse Konstrukten prepared Statements verwenden und prepare Strings grundsätzlich im Joblog protokollieren.
BTW: Der plan Cache nutzt hier eher nix, das Problem ist die Zuordnung zu der Ausführung (von Zigtausenden) ist selten möglich.

D*B

[mojo]

Wenn ich das recht in Erinnerung habe, dann sind PREPAREd Statements doch dynamische SQLs, richtig?

Falls ja, sind diese nich von der Performance her viel schlechter, weil der SQL-PreCompiler bei der Modulerstellung keine Zugriffspfade aufbauen kann?
Da werden doch dann bei jeder Ausführung des Statements aufs Neue die Zugriffspfade aufgebaut und das Statement optimiert, oder?

VG! mojo

[BenderD]

Wenn ich das recht in Erinnerung habe, dann sind PREPAREd Statements doch dynamische SQLs, richtig?

Falls ja, sind diese nich von der Performance her viel schlechter, weil der SQL-PreCompiler bei der Modulerstellung keine Zugriffspfade aufbauen kann?
Da werden doch dann bei jeder Ausführung des Statements aufs Neue die Zugriffspfade aufgebaut, oder?

... der Unterschied zwischen dynamic und static SQL liegt in den meisten praktischen Fällen unter der Messbarkeitsschwelle. Man kann ein Statement häufig einmal preparen und dann n mal ausführen, was den Aufwand minimiert , dann fällt der zusätzliche Aufwand nur einmal an und ab da hat man die gleiche Geschwinndigkeit wie bei static. Bei komplexen Statements wird der Access Plan zudem auch bei static SQL häufig dirty gesetzt und neu optimiert, sodass kein Unterschied zu dynamic SQL besteht.

D*B

[mojo]

OK, das ist doch mal eine gute Aussage!

Noch eine Frage:
Ich habe noch dunkel im Hinterkopf, dass vom SQL-PreCompiler bei der Modulerstellung auch temporäre Indizes erstellt werden, was bei dynamischen SQLs ebenfalls zur Laufzeit gemacht wird und hier die Laufzeit extrem erhöhen kann.
Ist das korrekt oder habe ich sich hier im Hinterkopf etwas verbuchselt?

mojo

[Fuerchau]

Der SQL-Compiler erstellt keine temporären Indizes (wäre ja noch schöner).

Alles zusammen wird in ein SQLPKG gepackt und in das Modul eingebettet (PRTSQLINF).
Zur Laufzeit werden dann die Optimierungen durchgeführt.
Ohne Prepare läuft aber sowieso nichts.
Statische SQL's werden bei der Verwendung "prepared", Dynamische SQL's werden entweder manuell per Prepare oder automatisch beim "Execute direct" prepared.
Dabei übernimmt die SQL-Runtime die Analyse.
Es werden (häufig) Konstanten dann automatisch in temporäre Hostvariablen überführt und Parametermarker eingesetzt (warum auch immer).
Es ist sogar noch nicht mal gewährleistet, dass 2 Open's mit unterschiedlichen Parametern den selben Zugriffsweg benutzen wobei nur die Wahrscheinlichkeit eben hoch ist.

Verschärft wird das seit V7R1 dahingehend, dass alle Namen zur Laufzeit geprüft werden müssen, ob sie in den Tabellen oder als Variable vorhanden sind.
Der Precompiler wirft nämlich keine Fehler mehr aus, wenn man sich bei Feldnamen vertippt hat.
Er geht nun davon aus, dass dies ja später vorhandene Variablen sein könnten.
Man kann also solche Fehler dann erst zur Laufzeit und nicht mehr zur Compilezeit finden zumal man bestimmte Buchstabendreher ja gerne überliest.

[BenderD]

OK, das ist doch mal eine gute Aussage!

Noch eine Frage:
Ich habe noch dunkel im Hinterkopf, dass vom SQL-PreCompiler bei der Modulerstellung auch temporäre Indizes erstellt werden, was bei dynamischen SQLs ebenfalls zur Laufzeit gemacht wird und hier die Laufzeit extrem erhöhen kann.
Ist das korrekt oder habe ich sich hier im Hinterkopf etwas verbuchselt?

mojo

- Irgendwelche Indexe legt der Compiler nicht an.
- Zur Compiletime wird ein Accessplan berechnet und in einem Package gespeichert (das ist eine Art vorläufiger prepare).
- Zur Runtime wird entschieden, ob der Accessplan noch verwendet werden soll.
- Static SQL wird zur Compiletime geprüft (soweit möglich)
- Accesspläne werden nach nicht dokumentierten Kriterien (es lohnt nicht drüber nachzudenken wie das im Moment gemacht wird, das kann sich ändern!!!) dirty gesetzt.
- ein statischer Accessplan kann schlechter sein als ein dynamisch ermittelter (das gilt für etliche Käse-Zaubereine)

Meine Empfehlungen:
- einfacher ist immer besser!!!
- Static wegen der Prüfungen bevorzugen
- first make it right
- Performance Optimierung nur wenn es tatsächlich zu langsam ist
- Hauptmaßnahme für Performance Optimierung ist das anlegen erforderlicher Zugriffspfade.
- (fast) alles andere ist Pille-Palle.

D*B

[mojo]

ein Punkt ist mir noch eingefallen.

-> Stichwort FULL OPEN

Wie ist es damit?
Bei einem DYNAMIC SQL muss ja vermutlich immer ein FULL OPEN gemacht werden, da sich ja auch die angesprochenen Tabellen ändern könnten, richtig?
Das sollte bei STATIC SQL nicht der Fall sein, oder?
Falls meine Vermutungen richtig sind wäre das bei großen Tabellen ggf. eine erheblicher Performance-Verlust, oder?

Könnte ich hierzu bitte auch noch eure fachkundige Meinung haben?

VG! mojo

[BenderD]

ein Punkt ist mir noch eingefallen.

-> Stichwort FULL OPEN

Wie ist es damit?
Bei einem DYNAMIC SQL muss ja vermutlich immer ein FULL OPEN gemacht werden, da sich ja auch die angesprochenen Tabellen ändern könnten, richtig?
Das sollte bei STATIC SQL nicht der Fall sein, oder?
Falls meine Vermutungen richtig sind wäre das bei großen Tabellen ggf. eine erheblicher Performance-Verlust, oder?

Könnte ich hierzu bitte auch noch eure fachkundige Meinung haben?

VG! mojo

... wieder einer von den Mythen:
- DB2/400 macht grundsätzlich einen lazy Close (versucht alle Tabellen offen zu halten)
- die einzige Operation, die einen Close sicher erzwingt ist ein disconnect
- ein full open dauert bei vorhandenem Index Millisekunden
- wenn da was länger dauert, dann liegt das am Aufbau eines temporären Index
- temporäre Indexe werden gecached (was bedeutet, dass ein erneuter open von der Größe einer Datei nicht abhängt und wieder Millisekunden dauert.
- guter Stil ist, dass man für unterschiedliche Tabellen und SQLs nicht dásselbe Statement/Cursor verwendet (warum auch?)

D*B

[mojo]

PERFECT!!

Vielen Dank in die Runde!
Hat mich einiges weiter gebracht!

VG! mojo