Wie dumm ist der SQL Optimiser eigendlich ..

[BenderD]

... ohne Witz: es soll Dienstleister geben, die auf einer Mini Büchse mit zu wenig Hauptspeicher an einen Controller die größten Platten dranhängen und dann soviel Workload draufnehmen, dass das weiße Ware schneller hingekriegt hätte - da können 5 Minuten für (fast) nix schon normal sein.

D*B

[Christian Bartels]

Ich würde mal vermuten, dass der Optimizer nur dann einen Temporary Sort auf die Ergebnismenge macht, wenn die erwartete Ergebnismenge in den Hauptspeicher passt, und zwar unter Berücksichtigung des "fair share", für den ich folgende Definition gefunden habe:

SQE fair share of memory = Memory Pool Size/ min(Max Active, max(Average Active Used,5))

The Average Active Used is the larger of the following two:
• 10% of the Max Active specified for the memory pool
• Average active in the pool* as reported back by the Storage Management

* Average active in the pool is defined as:
• 15 minute rolling average number of users in the pool when paging option is set to*CALC
• The no. of unique users in the pool in the last 2 seconds when paging option is set to*FIXED

(https://www.ibm.com/developerworks/i...active-pdf.pdf)

Interessant wäre, welche Implementierung gewählt wird, wenn das Statement 5 Minuten braucht - ich würde darauf tippen, dass ein temporärer Index erstellt wird. Mit STRDBMON/ENDDBMON und dem Explain aus Access Client Solutions könnte man das relativ leicht herausfinden.

Mit freundlichen Grüßen,
Christian Bartels.

[holgerscherer]

... ohne Witz: es soll Dienstleister geben, die auf einer Mini Büchse mit zu wenig Hauptspeicher an einen Controller die größten Platten dranhängen und dann soviel Workload draufnehmen, dass das weiße Ware schneller hingekriegt hätte - da können 5 Minuten für (fast) nix schon normal sein.

D*B

Kenn ich von "Kollegen". Gepflegte Überprovisionierung, ohne den Endkunden zu fragen, was überhaupt laufen soll.

Andererseits - es gibt Kunden, die bestellen bei "Dienstleistern" eine Umgebung mit X CPW, Y RAM und Z GB Disk. So günstig wie möglich. Und wundern sich dann, wenn sie es günstig kriegen ;-)

-h

[Robi]

Moin,
da muß ich euch entäuschen ...
die Kiste ist eher überdimensioniert als zu klein / zu schwach. Wurde von einer sehr renomierten großen Firma gemacht. Und sie läuft sehr gut.

Nur wenn sie 4 Sätze sortieren muß, ist ihr das zu langweilig und sie sortiert ca 8.000.000

Sonst wäre dieser Thread nicht entstanden ...

[Fuerchau]

Da kann ich auch nur zustimmen, dass der Optimizer da eher pessimistisch als optimistisch vorgeht.
Für die schnelle Abfrage ohne Order By wird mit Sicherheit ein Index existieren.
Für ein erstes Abschätzen wird dann die Index-Statistik (DSPFD) herangezogen. Hier ist im Wesentlichen die Anzahl der unterschiedlichen Schlüssel der Knoten vermerkt. Ab irgendeinem Prozentsatz wird der Index genommen oder eben nicht.
Kommt nun noch ein Order By dazu (ähnlich auch Group by) entscheidet dann bei fehlenden Indizes der Pessimizer dann auch gerne mal falsch und hält einen Tablescan für besser.

Allerdings muss ich auch dazu sagen, dass per STRSQL da durchaus anders optimiert wird (FIRSTIO) als z.B. bei embedded SQL oder auch ODBC (ALLIO).
Wobei ich die Optimize-Klausel da schon ausprobiert habe aber kein abweichendes Ergebnis zustande bekam.