SQL-Optimizer V7R1 und kein Ende

[andreaspr@aon.at]

Abfragen, die mit V6R1 noch 1-2 Sekunden gebraucht haben (mehrere 1000 Sätze) dauern nun mehrere (> 15) Minuten!

Also eine Abfrage die vorher 1-2 Sekunden gedauert hat, soll plötzlich 15 minuten benötigen??
Wenn das wirklich so ist, dann hat diese Kiste einiges an Problemen!!

Könnte es vielleicht an der ODBC Version liegen?

[Fuerchau]

Du kannst mir glauben, dass ich diesbezüglich alles bereits geprüft habe.
Das einzige, was ich nicht prüfen kann, das muss der Kunde selber, ist der aktuelle DB-PTF-Stand.

Was mich ärgert ist grundsätzlich das unterschiedliche Verhalten zwischen STRSQL und ODBC.
Selbst bei "optimize for 10000 rows" ist STRSQL einfach schneller.
Wie gsagt, ich weiß nicht was sich IBM dabei denkt.

[camouflage]

Vielleicht hilft Dir das weiter...

http://www-01.ibm.com/support/docvie...d=nas8N1015556

[Fuerchau]

Bitte entschuldige, aber das ist bereits ein alter Hut und wird von mir immer als erstes geprüft.

[Christian Bartels]

Speziell für den Datenbank-Optimierer in V7R1 gab es gerade ein Problem, das mit dem PTF MF57834 behoben wird.

Mit freundlichen Grüßen,
Christian Bartels.

[hs]

Wir hatten auch so komische Effekte auf unserer neuen Anlage mit OS 7.1
90% der SQL liefen so schnell, wie man es erwarten konnte. Aber einige - insbesondere wenn man mehrere Tabellen mit JOIN verknüpft hat, waren faktor 3 bis 4 langsamer.
PTFs haben nichts gebracht. Erst nachdem wir passende Indizes erstellt hatten, liefen diese so flott wie man es erwartet auf einer neuen Anlage.
Seltsam, auf der alten hatten wir die Indizes ja auch nicht...

[B.Hauser]

Im alten System/Release war vielleicht noch die CQE (Classic Query Engine) beteiligt, die anders arbeitet als die SQE (SQL Query Engine).
Die CQE ermittelt die Indices basierend auf Schätzwerten, d.h. bei einer Auswahl in den Where-Bestimmungen mit = wird von 10% der Daten ausgegangen, bei <= von 33% der Daten etc. das ganze wird zusammengemischt und ausgerechnet etc.
Die SQE arbeitet mit Statistiken, d.h. also der echten Datenzusammensetzung und bewerte die Zugriffswege auf dieser Basis.
Ein Index-Access wird nur ausgeführt, wenn weniger als 15 max. 20% der Daten einer Tabelle/Datei ausgewählt werden.
Damit können beide Query-Engines zu unterschiedlichen Ergebnissen kommen, d.h. Zugriffswege, die die CQE aufgrund der Schätzwerte ermittelt hatte, konnten bei der SQE basierend auf den Echt-Daten nicht mehr verwendet werden.

[Fuerchau]

Warum ist ein Index mit max. 20% der daten ungünstig?
Das ist doch glatt ein Designfehler.
Selbst wenn ich 100% der Daten benötige, könnte SQL sich ja zumindest den Sort sparen, was bei ein paar Mio Sätzen durchaus performance bringt.
Auch wenn ich 30% von z.B. 100 Mio Sätzen benötige wäre eine Indexverwendung jedenfalls die bessere Alternative.
Da sollte IBM mal nachbessern und die Prozente ignorieren.
Wenn ein Index passt, ins besonders ein Compound-Index (mehrere Felder) sollte dieser auch verwendet werden.

[andreaspr@aon.at]

Ich glaub die IBM wird sich diese Werte nicht aus den Fingern herbeigezogen haben
Bei einem Sort wird natürlich, wenn vorhanden, ein Index benützt!

Der Performance-Nachteil (außer bei einem Index-Only-Access) ist, dass bei einem Index für die Werte der Spalte der Baum von Oben bis Unten durchgegangen werden muss. Und wenn die DB dann den entsprechenden Wert am Ende des Baumes hat muss sowieso nochmal zusätzlich auf die entsprechende Stelle in der Tabelle zugegriffen werden um sich den ganzen Satz zu holen.
Wenn also sowieso ein sehr großer Teil der Daten benötigt wird, kann die DB gleich die eigentliche Tabelle lesen gehen und braucht nicht ständig hin und her springen.

Wenn man sich diesen Prozess auf Blockebene ansieht und sieht wann, was, wie, wohin gelesen werden muss ist es einfacher.
Nebenbei: bei Oracle ist es nicht anders.

lg Andreas

[Fuerchau]

Wenn ich mir so die Zugriffsverfahren ansehe und die Ergebnisse betrachte, so kann ich die 20%-Regel nicht nachvollziehen.
Mache ich einen Select, der mir aus 10Mio Sätzen ca. 1/3 der daten liefert, und ein passender Index vorhanden ist, so weist der Optimizer diesen zumindest aus.
Das Ergebnis kommt auch schneller als bei einem Select, der einen Tablescan durchführt.

Bei Oracle kann ich das z.T. nachvollziehen. Beim Laden von Daten aus einer Oracle-DB, die Daten werden per View bereitgestellt, dauert es mitunter doch sehr lange bis der 1. Satz geliefert wird obwohl (angeblich) Indizes vorhanden sind.

Ich habe aber auch festgestellt, dass ins besonders beim Group by der zwangsweise Verzicht auf die Verwendung eines Index, wenn eine Where-Bedingung mit passendem Index vorhanden ist, schneller zum gewünschten Ergebnis führt.
Dazu behelfe ich mir mit folgendem SQL:

select coalesec(key1, key1) key1, coalesec(key2, key2) key2, sum(feld)
from mytable
where "Irgendeine Bedingung"
group by coalesec(key1, key1), coalesec(key2, key2)

Durch das coalsece wird die Verwendung eines Index für Group By verhindert, da dies ja ein "berechnetes" Ergebnis darstellt.
Allerdings wird für das Where der korrekte Index verwendet.
Lass ich den coalesce weg, wird der Index der Key-Felder verwendet, wobei diese ja durch die Where-Klausel noch eingeschränkt werden müssen.

Klar, jede DB implementiert anders um schnell zum Ergebnis zu kommen, manchmal halt nicht so schnell.

[BenderD]

... wie sich Klein Fritzchen/Erna die Berechnung eines Zugriffsplans so vorstellt...
Im richtigen Leben werden immer Blöcke in den Hauptspeicher geladen und das ist das, was wirklich Zeit verbraucht. Alles, was dann Speicher resident passiert, wird vernachlässigt, da dies um Größenordnungen schneller ist, als Ein/Auslagerung von Platte. Von Zeit zu Zeit ändert sich dieses zeitliche Verhältnis, durch anders balancierte Hardware (seit RISC hat die AS/400 wesentlich mehr CPU Power, in letzter Zeit sind die Hauptspeichergrößen stark gestiegen) und dann passen sich die Optimierungs Algorithmen daran an.
Bei allen Optimierungsvorgängen sind Schätzungen über die Größe und Verteilung von Ergebnismengen (können auch Zwischenresultate sein) im Spiel, da helfen auch run Statistiken nur sehr begrenzt. Ändert sich bei neuen Releases was zum Negativen sind das mit höchster Wahrscheinlichkeit Bugs, wohl dem der Database Monitor Daten zum Vergleich hat, der findet hier schnell Work arounds. Für alle Daumenregeln, wie die genannten gibt es reichlich Ausnahme Konstellationen. Sind die Zugriffsprobleme kritisch, weil z.B. ein Programm nicht mehr in der benötigten Zeit fertig wird, hilft nur eine saubere Analyse (Database Monitor) alle Schnellschuß Empfehlungen sind Klugschwätzerei und/oder Scharlatanerie. Letzteres gilt nicht nur für DB2/400, sondern für alle Datenbanken.

D*B

[B.Hauser]

Eins kannst Du glauben, die Schätzwerte beruhen auf Erfahrungswerten.

Begingt durch die Baum-Struktur sind Zugriffe mit (Binary Radix Tree) Indices bei größerem Datenvolumen zu langsam.
Der Optimizer kann jedoch für eine einzige Abfrage mehrere Indices gleichzeitig und auch sub-optimale Indices verwenden und die Ergebnisse in Bitmaps zwischenspeichern und die Bitmaps angschließend auswerten.

Eine Sortierung ist keine Voraussetzung für die Verwendung eines Idices. Die Sortierung ist das letzte Kriterium, das bei der Optimierung herangezogen wird. Das Hauptziel ist es so schnell wie möglich an die Daten zu kommen. Da ist es manchmal geschickter Informationen in temporären Objekten zwischen zu speichern und erst am Schlusse das Zwischen-Ergebnis zu sortieren.

IBM hat allerdings nachgearbeitet, indem sie EVIs (Encoded Vector Indicses) zur Verfügung gestellt hat, die jedoch entweder ignoriert oder als Lachnummer abgetan werden.
Sofern die passenden EVIs vorhanden sind, können diese verwendet werden sofern zw. ca. 20 und 80% der Daten ausgewählt werden.

... ansonsten ist die Optimierung halt doch noch ein bisschen komplexer.

@Baldur: Wenn der Index passt, warum nimmt Du dann nicht native I/O, der verwendet die angegebene logische Datei oder SQL Index ohne Wenn-und-Aber.

Birgitta