Ferne SQL Analyse / Performance

[pwrdwnsys]

So, lange Analyse, und im Endefeffekt einige Statements von gut 1 min Laufzeit auf unter 1s gedrückt. Das Problem sind die Statements selbst. Und hat auch nichts mit den Aliasnamen zu tun. Der Optimizer der AS400-DB2 scheint schlechter zu arbeiten als der LINUX-DB2 Optimizer. Denn der zeigt bessere Ergebnisse und verwendet auch bei gleichen Tabellen / Indizes solche.
Beispiel :

SELECT A.FLD1, A.FLD2, A.FD3, B.FLD1, B.FLD2
from TABELLE1 A, TABELLE2 B where A.FLD1 = B.FLD1
and B.FLD2 in (select C.FLD2 from TABELLE3 WHERE C.FLD3 = X and C.FLD4 = y)

Soweit sogut.Viele Tests mit Views / Indizes haben nix gebracht. Das Statement anders formuliert geht granatenschnell.

SELECT A.FLD1, A.FLD2, A.FLD3, B.FLD1, B.FLD2, C.FLD3, C.FLD4
from TABELLE3 C, TABELLE1 A, TABELLE2 B
where A.FLD1 = B.FLD1
and B.FLD2 = C.FLD2C.FLD2
where C.FLD3 = X and C.FLD4 = y

Und jetzt kommts : Wenn ich in der FROM-Klausel die Tabellenreihenfolge ändere (Tabelle C weiter hinten) dann wirds wieder wesentlich langsam.

SELECT A.FLD1, A.FLD2, A.FD3, B.FLD1, B.FLD2, C.FLD3, C.FLD4
from TABELLE1 A, TABELLE2 B, TABELLE3 C
where A.FLD1 = B.FLD1
and B.FLD2 = C.FLD2C.FLD2
where C.FLD3 = X and C.FLD4 = y

Anders ist die Datenbank nicht zur performanten Zusammenarbeit zu bewegen. Eigentlich fast logisch, denn die Ergbnismenge von C ist (in diesem Fall) die kleinste. Dabei handelt sich aber um eine Tabell mit gut 1.000.000 Datensätzen

[BenderD]

Hallo,

so nach dem Urlaub noch ein paar gesammelte Anmerkungen:
- der Query Otimizer (besser Pessimizer) ist milde ausgedrückt wirklich nicht der beste
- falls es sich um V5R3 handelt, spricht vieles für einen Bug, egal welches Phänomen zu beobachten ist.
- alles was Rekursion beinhaltet ist meist langsam und kann durch Umformulierung in einen Join (soweit möglich) schneller gemacht werden
- Feldnamen sollte egal sein
- unter 50 Indexen sollte der Pessimizer locker fertig werden, sonst ist was anderes faul.
- Indexe werden ignoriert, wenn die CCSID nicht matched
- bei JDBC gab es auch schon Probleme mit dem extended dynamic package support
- die Begeisterung über die neue Query Engine kann ich nicht teilen, da habe ich Verbesserungen nur beim parallel Database Feature gesehen und vieles andere, was schlechter geworden ist, sieht alles sehr nach Beta Version aus.
- für die Telnet Problematik: da könnte man auch den Debug aktivieren (per Driver Option? habe ich nicht im Kopf) oder per stored Procedure Aufruf, oder per STRSRVJOB - dann werden die Diagnostics ins Joblog gemalt.
- zu Visual Explain fällt mr nur ein, dass ich die Schnittmusterbogen meiner Oma auch nie verstanden habe.

mfg

Dieter Bender

[Fuerchau]

Seit der Umstellung auf V5R3 kann ich bezüglich dem Pessimzer Dieter nur zustimmen. Die geschätzten Abfragezeiten sind teilweise um Faktor 1000 - 10.000 zu hoch !!!

Da wird eine Abfrage (mit Union-Select über ca. 2 Mio Sätze) mit über 100.000 Sekunden geschätzt wobei die tatsächliche Abfrage dann nur ca. 15 Sekunden benötigt.

Es gibt allerdings kurzfristig eine Umgehung:

Wird eine LF (mit DDS und keine SQL-VIEW) mit SELECT/OMIT erstellt erzwingt man die Verwendung des alten Optimizers und siehe da, plötzlich werden die Zugriffspfade wieder korrekt verwendet und die Zeiten liegen "nur noch" um Faktor 10-100 daneben.

Allerdings konnte IBM keine Aussage treffen, ab wann der neue "Optimizer" auch LF's mit Select/Omit berücksichtigt. Es kann also mit irgendeinem PTF/Update plötzlich wieder zu pessimistischen Zeitschätzungen kommen.