SQL Performance bei Aggregatfunktion

[andreaspr@aon.at]

Ich kann mich nur der getKey-Methode anschließen.

Ansonsten kann es auch daran liegen, dass ...
*) ist die Reihenfolge vom Index falsch ist
*) der Index nicht verwendet werden kann, weil SQL intern Casten muss.
*) euer Release 6.1 oder kleiner ist, es ein Index ist mit Select/Omit und in der QAQQINI Ignore d. index gesetzt ist.
*) usw.

Wird denn überhaupt ein Index verwendet, wenn er alle Sätze liest?

lg Andreas

[dschroeder]

Erstmal vielen Dank für die zahlreichen Antworten.
Hier noch ein paar Fakten dazu:

- Wir sind auf V7
- Der passende Index wird verwendet (laut Visual Explain)

Der Ablauf bei Visual Explain ist folgender:
1.) Index Probe
2.) Temporary List
3.) List Scan
4.) Final Select

Die Idee mit der Key-Tabelle passt mir für diese Aufgabenstellung im Moment nicht so gut. So eine Tabelle setzen wir im Moment immer da ein, wo wir globale IDs für Tabellen ermitteln (genauso, wie ihr das beschrieben habt: mit Sperrung).

Ich habe das betreffende Programm eben mal in einer Testumgebung so umgebaut, dass es nicht mit SQL arbeitet, sondern mit SETGT und READPE. Jetzt ist läuft das Programm in 30 Sekunden durch. Mit SQL dauert es 4 Minuten.

Meine eigentliche Frage ist, ob man davon ausgehen muss, dass SQL bei Aggregatfunktionen (insbesondere bei Max) viel langsamer ist als ein "manueller" Zugriff mit RPG-Bordmitteln. Wenn das so ist, muss man das eben hinnehmen und genau hinschauen, wann man welches Verfahren verwendet.

Dieter

[BenderD]

... bei Aggregat Funktionen ist SQL im Allgemeinen schneller und im speziellen Fall langsamer und hier habt ihr es mit einem solchen zu tun.
DB2 auf der AS/400 ist immer noch optimiert für sequentiellen und ISAM (Index sequentiellem) Zugriffe. Das ändert sich nicht durch Marketing Aussagen (SQL ist immer schneller), egal wer das alles glaubt (soll es hier im Forum auch geben) und wird solange so bleiben, wie unter der Oberfläche eine ISAM Datenbank liegt.

D*B

[dschroeder]

Vielen Dank für die Antwort.
Das bestätigt meine Vermutung. Wenn man das weiß, kann man sich beim Programmieren ja darauf einstellen.

Gruß,
Dieter

[andreaspr@aon.at]

Lest ihr den neuen Key in der Anwendung an einer zentralen Stellen ein (Prozedur, Programm)?
Wenn du ein SELECT INTO machst erstellt das System automatisch einen Cursor dafür. Wenn du das SELECT INTO nun an verschiedenen stellen machst, hast du mehrere Cursor bei denen jedes mal der Datenpfad geöffnet werden muss.

In RPG macht man ja auch nicht ständig ein OPEN(Tabelle).

Starte einfach mal einen Performance Monitor.
Dort siehst du dann auch wie oft der Datenpfad geöffnet wurde und wie oft er wieder verwendet worden ist.
Im Idealfall muss er maximal 2 mal geöffnet werden.

[dschroeder]

Wir haben ein Serviceprogramm, das den neuen Key ermittelt. Das ist die einzige Stelle, die das macht. Allerdings wird das Serviceprogramm von verschiedenen Programmen aufgerufen.

[B.Hauser]

Wir haben ein Serviceprogramm, das den neuen Key ermittelt. Das ist die einzige Stelle, die das macht. Allerdings wird das Serviceprogramm von verschiedenen Programmen aufgerufen.

Wenn die Programme in unterschiedlichen Aktivierungsgruppen laufen und das Service-Programm mit Aktivierungsgruppe *CALLER erstellt wurde, kannst Du innerhalb eines Jobs mehrere Duplikate haben und folglich mehrere FULL OPENS, da jedes SQL-Statement seinen eigenen ODP erhält.

Birgitta

[dschroeder]

Das ist bei uns sicher der Fall. Das eigentliche Performanceproblem wird aber durch große Schleifen ausgelöst, in denen immer wieder in die Datei geschrieben wird. Ich hoffe, dass da nicht immer wieder ein Datenpfad neu geöffnet werden muss.

Dieter

[andreaspr@aon.at]

... und damit kommen wir wieder zum Stichwort Performance Monitor
Dort siehst du dann sogar in der Zusammenfassung ganz am Anfang welche und wieviele OPENs gemacht wurden.

lg Andreas

[dschroeder]

Mit dem Performance Monitor tue ich mich immer wieder etwas schwer. Wir benutzen das Tool so selten. Deshalb ist es immer wieder etwas aufwendig, da einzusteigen.

Aber wahrscheinlich muss ich das wohl machen.

Dieter

... und damit kommen wir wieder zum Stichwort Performance Monitor
Dort siehst du dann sogar in der Zusammenfassung ganz am Anfang welche und wieviele OPENs gemacht wurden.

lg Andreas

[Fuerchau]

Die Aggregat-Funktion geht natürlich auch über den Index und macht auch in diesem Fall einen Index-Only-Access.
In wie weit die MAX-Funktion eben einen absteigenden Index verwendet (optimiert ist) kann ich nicht sagen.
Allerdings ist MAX eben so definiert, dass in einer Liste der größte Wert ermittelt werden soll.
Und das genau tut eben SQL (siehe Visual Explain).

Wie gesagt, mit einem explziten Zugriff per Order By auf 1 Satz sollte es auch funktionieren.

RPG ist dann langsamer, da immer auch auf die Datenbereiche zugegriffen wird, während SQL eben nur den Index-Teil verwenden kann.

[dschroeder]

Ach, jetzt habe ich verstanden, weshalb du einen absteigenden Index haben wolltest: Du meinst, auf max() verzichten und stattdessen einen cursor öffnen und den ersten Satz lesen. Das könnte man wirklich nochmal versuchen!

Dieter