Performance-Problem bei Emmbeded SQL

[mott]

Hallo Forums-Mitglieder!

Ich habe folgendes Problem: Ich habe ein ILE-RPG Programm mit embedded SQL, das für die SQL Anweisung einige Minuten benötigt. Führe ich das selbe SELECT-Statement mit dem interaktiven SQL aus, dauert dies lediglich 2 Sekunden. Im Joblog habe ich dann gesehen, dass beim interaktiven SQL eine logische Datei verwendet wird, die beim embedded SQL nicht herangezogen wird.

Hat von euch jemand eine Ahnung, woran dies liegen könnte.

Vielen Dank im Voraus für eure Antworten!
Michael

[Fuerchau]

Das kann dir nur eine Analyse im Debug-Modus zeigen (Joblog).
Häufig ist der Grund, dass Parameter ( :Feld) in der Ausprägung nicht stimmen (Länge, Typ, ...).
Interaktiv kann man ja nur mit Konstanten abfragen, daher besteht dort das Problem meist nicht.

Ausserdem wird intern für eine schnelle Anzeige meist anders optimiert (optimize for x rows).

[B.Hauser]

Besser ist eine Analyse über den iSeries Navigator.

- Datenbanken
- SQL Leistungs-Überwachungen --> Rechte Maustaste Neu --> Details
- Analayse für den Job starten, in dem das embedded SQL läuft.

Anschliessend die Aufzeichnung auswählen, Rechte Maustaste und erklärbare Anweisungen auflisten.

Visual Explain bietet u.a. auch einen Index-Advisor, der den/die benötigten Indices auflistet. Per Knopfdruck können diese einfach angelegt werden.
(Auch wenn nicht jeder Index, der angelegt wird gezogen wird, sollte man ihn nicht löschen, da Indexe auf zum Erstellen der Statistiken herangezogen werden)

Abweichungen zwischen interaktivem und embedded SQL kann es geben, wenn z.B. andere Feld oder Satz-Auswahlen getroffen wurden.

[Fuerchau]

@Birgitta
Jein !

Auch hier hilft die Analyse ggf. nicht, wenn man Hostvariablen über Schlüssel anwendet, die von der Ausprägung nicht stimmen !

Wenn ich z.B. ein DEC-Feld in der Tabelle mit einem INTEGER-Feld im Programm abgleiche, wird ein Zugriffspfad mit fem Typ INTEGER aufgebaut. Da hilft leider keine Analyse.

[BenderD]

Hallo,

die Geschmäcker sind verschieden, für mich ist dieser iSeries Navigator ein notwendiges Übel, weil man ansonsten noch größere Probleme hätte die völlig denormalisierten Daten des Database Monitors zu interpretieren.
Aber seis drum:, bei Differenzen zwischen Programm und interaktiv hilft nur messen, egal ob man die Messung aus dem Mäusekino startet oder von der Commandline.
Potentielle Ursachen liegen eher in Baldurs Richtung. Mit dem blinden Anlegen von Indices wäre ich eher skeptisch, da passiert auch viel Mist und an die glorreichen statistics und deren Nutzen glaube ich vorerst nicht, das ist doch (fast und noch) alles Marketing Gesülze. Für gezieltere Hinweise, woran das liegen könnte, wäre ein wenig Code und mehr Beschreibung hilfreich.

mfg

Dieter Bender

Besser ist eine Analyse über den iSeries Navigator.

- Datenbanken
- SQL Leistungs-Überwachungen --> Rechte Maustaste Neu --> Details
- Analayse für den Job starten, in dem das embedded SQL läuft.

Anschliessend die Aufzeichnung auswählen, Rechte Maustaste und erklärbare Anweisungen auflisten.

Visual Explain bietet u.a. auch einen Index-Advisor, der den/die benötigten Indices auflistet. Per Knopfdruck können diese einfach angelegt werden.
(Auch wenn nicht jeder Index, der angelegt wird gezogen wird, sollte man ihn nicht löschen, da Indexe auf zum Erstellen der Statistiken herangezogen werden)

Abweichungen zwischen interaktivem und embedded SQL kann es geben, wenn z.B. andere Feld oder Satz-Auswahlen getroffen wurden.

[B.Hauser]

Wenn ich z.B. ein DEC-Feld in der Tabelle mit einem INTEGER-Feld im Programm abgleiche, wird ein Zugriffspfad mit fem Typ INTEGER aufgebaut. Da hilft leider keine Analyse.

Falsch!

Eine Typen-Konvertierung erfolgt, sofern erforderlich, im Select-Statement, d.h. gegebenenfalls werden Funktionen eingebunden, die Datentypen umsetzen.
Diese zusätzlichen Aufrufe können dann die Verarbeitung ausbremsen.

Erst danach wird nach dem/den optimalen Zugiffsweg(en) gesucht.

Ein Index kann immer nur über bestehende Datei-Felder angelegt werden. Dabei spielt es keine Rolle, ob es sich um einen permanenten oder temporären Index handelt.

Wird ein temporärer Index angelegt oder ein Table Scan ausgeführt, hat dies u.U. andere Ursachen. Da bleibt oft wirklich nur Versuch und Irrtum.

@mott
Eine unterschiedliche Daten-Konstellationen oder Release-Stände zwischen Test- und Echt-Umgebung können den Query Optimizer zu völlig anderen Entscheidungen kommen lassen.

@Dieter
Visual Explain ist im Moment das Beste was IBM in dieser Beziehung zu bieten hat.

Und ... in einer normalisierten Datenbank wird man ausserdem nur eine kleine Anzahl Indices pro Datei benötigen

Birgitta

[BenderD]

Hallo,

mit der Anzahl der Indices und der Normalisierung bin ich voll bei dir.
Das mit den Konvertierungen, das ist wohl eine elementare Schwäche des Query Optimizers (Pessimizer?). Ich habe definitiv vor kurzem einen Query von der Art
SELECT .... from ..... where Feld = xyzCAST(:Feld)
gesehen, der mit dem Aufruf der Konvertierung einen full tablescan ausgelöst hat, der nach Konvertierung des Feldes im Programm weg war.
Das mit dem Visual Explain, so hart wollte ich das garnicht formulieren, das die anderen Sachen alle noch schlechter sind.

mfg

Dieter

Falsch!

Eine Typen-Konvertierung erfolgt, sofern erforderlich, im Select-Statement, d.h. gegebenenfalls werden Funktionen eingebunden, die Datentypen umsetzen.
Diese zusätzlichen Aufrufe können dann die Verarbeitung ausbremsen.

Erst danach wird nach dem/den optimalen Zugiffsweg(en) gesucht.

Ein Index kann immer nur über bestehende Datei-Felder angelegt werden. Dabei spielt es keine Rolle, ob es sich um einen permanenten oder temporären Index handelt.

Wird ein temporärer Index angelegt oder ein Table Scan ausgeführt, hat dies u.U. andere Ursachen. Da bleibt oft wirklich nur Versuch und Irrtum.

@mott
Eine unterschiedliche Daten-Konstellationen oder Release-Stände zwischen Test- und Echt-Umgebung können den Query Optimizer zu völlig anderen Entscheidungen kommen lassen.

@Dieter
Visual Explain ist im Moment das Beste was IBM in dieser Beziehung zu bieten hat.

Und ... in einer normalisierten Datenbank wird man ausserdem nur eine kleine Anzahl Indices pro Datei benötigen

Birgitta

[Fuerchau]

Da kann ich Dieter nur zustimmen.
Der Tablescan / Indexaufbau erfolgt auf Basis des Feldes der Where-Bestimmung.
Das gleiche gilt übrigens auch, wenn bei einer Join-Beziehung die Feldtypen nicht zueinander passen. Auch in diesem Fall konvertiert der Optimizer die Datenbank (bzw. Index-Anlage) und nicht intern nur das Feld !!!

Um also performante Ergebnisse zu erzielen, ist es UNABDINGBAR zumindest die Feldtypen von Join und Where zu Programmvariablen (Parametern) abzugleichen bevor man mit irgendwelchen Tools (Visualirgendwas) an weitere Analysen geht.
Zumindest hierbei konnte ich mich IMMER auf die Debug-Angaben des Joblog's verlassen.

[BenderD]

Bei den nichtpassenden Join Bedingungen hat die Database Engine ja eigentlich keine Möglichkeit Zugriffspfade zu nutzen, da hilft nur Redundanz (zusätzliches Feld mit passendem Datentyp), aber bei dem angeführten Beispiel ist das ein schlichtes Armutszeugnis und lässt mich bezweifeln ob es eine neu Database Engine gibt, oder es sich um ein Rebranding durch das Marketing handelt (früher nannte man das alter Wein in neuen Schläuchen).
Das Verhältnis zwischen den Debug Meldungen, dem Database Monitor und dem Visual Explain ist einfach benannt: das basiert alles auf den Daten, die der Database Monitor liefert und wenn es Abweichungen bei verschiedenen Ablaufumgebungen gibt, dann muss man genau auf den Daten von Laufzeitmessungen aufbauen, alles ander ist Quark. Ob man dann lieber liest, oder lieber Bildchen anschaut, das ist pure Geschmacksache; ich bevorzuge lesen und selber analysieren, wenn visual explain schlaue Vorschläge macht, dann frage ich mich warum er die nicht gleich der Query engine macht!!!
Bei Oracle kann man sowas konfigurieren und selbst MySQL geht diesen Weg!

Dieter

Da kann ich Dieter nur zustimmen.
Der Tablescan / Indexaufbau erfolgt auf Basis des Feldes der Where-Bestimmung.
Das gleiche gilt übrigens auch, wenn bei einer Join-Beziehung die Feldtypen nicht zueinander passen. Auch in diesem Fall konvertiert der Optimizer die Datenbank (bzw. Index-Anlage) und nicht intern nur das Feld !!!

Um also performante Ergebnisse zu erzielen, ist es UNABDINGBAR zumindest die Feldtypen von Join und Where zu Programmvariablen (Parametern) abzugleichen bevor man mit irgendwelchen Tools (Visualirgendwas) an weitere Analysen geht.
Zumindest hierbei konnte ich mich IMMER auf die Debug-Angaben des Joblog's verlassen.