Performance-Problem bei Emmbeded SQL

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