DEBUG - Abgesetzten SQL herausfinden

[Fuerchau]

Trotzdem muss STRSQL hier noch anders reagieren oder arbeiten, denn alle Varianten der Optimize-Klausel führen zu absolut keinen unterschiedlichen Ergebnissen.
Klar ist, dass bei ODBC ALLIO verwendet wird, da ja das Resultset komplett gebraucht wird.

Bei der CQE konnte ich jedenfalls beobachten, dass der Index verwendet wurde während die SQE dies nun nicht tut. Ich weiß auch nicht wie die SQE hier schätzen kann, da der verwendete SQL eigentlich keine Schätzung erlaubt:

select * from kunden
where Mandant = 1 and kundennr in (select kundennr from Rechnungen where Mandant=1 and Rechnungsdatum >= 20150101)

Bis vor wenigen Tagen reichte ein Index auf Rechnungen mit Mandant/Rechnungsdatum.
Nun musste ein Index Mandant/Kundennr/Rechnungsdatum erstellt werden.
Wobei sich dieser Index für mich nicht erklärt, da damit mehr Informationen gelesen werden müssen weil das Rechnungsdatum entscheidend ist.

In der Diagnose wird noch eine andere ominöse Optimierung ausgeworfen:
Es wird ein "left join datei2 b on a.k1=b.k1 and a.k2=b.k2 and a.k3=b.k3 and a.k4=b.k4" verwendet.
Der vorhandene Index für Datei2 ist K1/K2/K3/K4!
Die Indexempfehlung ist aber K1/K2/K4/K3?

Es wurden in letzter Zeit keine PTF's installiert, nur das Datenvolumen ist gewachsen.

[BenderD]

... der Index Mandant, Kundennummer, Rechnungsdatum erlaubt einen Index only access für den Subselect in der in Klausel (und kann auch eine Abschätzung für die Selektivität liefern).

D*B

[Fuerchau]

OK, das könnte ein Argument sein, wobei ich wieder Mandant/Rechnungsdatum/Kundennr vorziehen würde. Allein dadurch würde ich schon ca. 2,8 Mio. Keys weniger benötigen.
Mal sehen, vielleicht probiere ich das mal aus.

[BenderD]

... die where in (subselect) Abfragen haben häufig eine Tendenz zum full table scan und in diesem Fall bezieht sich der wirksame Selektor auch noch auf die größere Tabelle. Solche Abfragen sind anfällig für Wechsel in der Zugriffsstrategie. Wenn man selber Zusatzinformationen über die Selektivität hat, kann man eventuell versuchen über eine Order by clause eine Entscheidung nahezulegen. Oder die mehrstufige Variante, die immer schnell ist (in diesem Fall könnte man den subselect in eine UDT packen, das funzt dann,bis die UDTs ordentlich implementiert sind...)

Dieter

[AG1965_2]

Witzig, die Maschine sammelt Infos wie die NSA, kann aber scheinbar genau so selten sinnvolle Schlüsse daraus ziehen. :-)

[Fuerchau]

Häufig kann man die "in select(..)"/"not in (select..)" durch eine Exists-Klausel beschleunigen, da hier häufig nur ein Zugriff erfolgt.
Die Exists-Klausel wurde meines Wissens nach erst mit V4R5 eingeführt.
Leider habe ich noch genau einen AS/400-Kunden mit V4R3 (man glaubt es kaum).
Hier existiert der Exists nicht (schönes Wortspiel).

[KingofKning]

Witzig, die Maschine sammelt Infos wie die NSA, kann aber scheinbar genau so selten sinnvolle Schlüsse daraus ziehen. :-)

Der Spruch ist gut.....

GG