SQL Optimierung V5R4

[andreaspr@aon.at]

Blöde Frage (déja vu) Wie öffnest Du Visual Explain? Ich habe mir die Auswertung der Ergebnis-Datei mit Query angesehen.GG

Im System i Navigator. Dort werden die Auswertungen hübscher dargestellt und dort gibt es auch den Visual Explain.
Deine Verbindung --> Datenbanken --> DeineDB --> SQL Perf. Monitors --> ...

[Pikachu]

Vielleicht kannst du die UDFs optimieren?

Zum Beispiel, falls sie die gleichen Ergebnisse für die selben Eingabewerte liefern:

"Use the DETERMINISTIC option on procedures and UDFs that return the same results for identical inputs. This allows the optimizer to cache the results of a function call or order where the function is called in the execution stream to reduce the run time."

[Fuerchau]

Das Problem ist und bleibt die Verwendung von UDF-Ergebnissen in Where usw.
Hier erfolgt halt immer ein Tablescan und ist deshalb nicht optimierbar.
Deterministic hilft in diesem Fall auch nicht. Dies spart ggf. den Aufruf der UDF aber nicht den Tablescan. Wobei die Anzahl der Caches nicht unendlich ist.
Durch die Verlagerung in eine View ist das von außen noch nicht mal sichtbar.
Die UDF wird vor der Prüfung der restlichen Where's aufgerufen!

[KingofKning]

Also wenn ich sehe das die Original Datei mal gerade 72 Mio Sätze hat und der erzeugte Index dann 20.000 Einträge hat braucht der Sasck 2 Minuten 50 um den ersten Satz anzuzeigen.

Das dumme ist das die UDF wiederum auf eine View zurückgreift.
Das zu optimieren wird schwierig, vermutlich werde ich jeweils eine Datei erzeugen und die mit join in die Original-Datei einbinden.Nicht schön aber selten.

GG

[BenderD]

... was machen Deine UDFs denn überhaupt?

[Fuerchau]

SQL verwendet keine Indizes die Einschränkungen aufweisen.
Deine 20.000 Indexeinträge deuten auf eine Select/Omit-LF hin.
Diese kannst du im SQL getrost vergessen!

Besser ist hier ein Index, der die Select/Omit-Felder enthält, der ist dann verwendungsfähig.
Die View muss dann allerdings hier die Where-Klausel enthalten.

[KingofKning]

SQL verwendet keine Indizes die Einschränkungen aufweisen.
Deine 20.000 Indexeinträge deuten auf eine Select/Omit-LF hin.
Diese kannst du im SQL getrost vergessen!

Besser ist hier ein Index, der die Select/Omit-Felder enthält, der ist dann verwendungsfähig.
Die View muss dann allerdings hier die Where-Klausel enthalten.

Den Index den ich erstellt habe hatte nur Sortierangaben, aber keine Einschränkungen

[KingofKning]

... was machen Deine UDFs denn überhaupt?

Wie schon gesagt: Wir setzen die Software RP-Trade für unseren Außendienst ein, und die benötigt natürlich alle möglichen Kundeninformationen.
Da meine SQL-Kenntnisse nur rudimentär sind, habe ich die Aufgabe in div. Teilaufgaben gesplittet. Sprich eine UDF holt mir die Umsätze des Kunden, eine andere UDF holt mir die Planzahlen, die dritte die letzten Aufträge etc. Ich habe dann eine View erstellt in der ich alle Informationen zusammengefasst habe um daraus eine Text-Datei für den FTP Upload zu erstellen.
Brigitta könnte sicherlich ein komplexes SQL erstellen das die Aufgabe besser und schneller löst ;-).
Ich habe gestern nochmals mit dem strdbg experimentiert und spaßeshalber mal den vorgeschlagenen Index angelegt, es ist aber wie von Fuerchau vorhergesagt unnütz da der Index nicht genommen wird.

Also werde ich wie gesagt die Abfragen (UDFs) in ein CL packen und einzeln ablaufen lassen und die Ergebnisse jeweils in eine Datei stellen die ich dann ohne Performanceverluste in der View integriere.

GG

[BenderD]

... das wären dann doch UDTF (Table Functions) und das sind in den meisten Konstellationen gefürchtete Penner. Das geht doch mit views oder subselects genauso und mit views ist das dann doch einfacher und bei entsprechenden Indexen schneller.