SQL Ersatz für SETGT/READE Kombi

[B.Hauser]

Für Einzelsatz-Zugriffe ist SQL im Vergleich zu RPG um einiges langsamer, das ist bekannt. Der Faktor 1:10 erscheint mir allerdings etwas hoch.

Nur so ein paar Fragen am Rande.
Befinden sich die aufrufende Prozeduren und die rufenden Prozeduren im gleichen Modul?
Befinden sich die aufgerufenen Prozeduren in einem Service Programm oder sind die Module gebunden?
In welcher Aktivierungsgruppe werden die Caller und aufgerufenen Prozeduren ausgeführt?
Wie wird die Option CLOSQLCSR im Umwandlungsbefehl (oder SET OPTION Statement) der (embedded) SQL Module gesetzt? *ENDMOD oder *ENDACT?

Birgitta

[mwithake]

Die Prozedur befindet sich im einem Serviceprogramm, das mit ACTGRP(*CALLER) umgewandelt wird. Der Parameter CLOSQLCSR im CRTSQLRPGI, mit das Serviceprogramm erstellt wird, steht auf *ENDACTGRP, SET OPTION wird nicht verwendet.
Das aufrufende Programm hat die Aktivierungsgruppeneinstellung *NEW.

[BenderD]

... da komme ich auf > 7.000 pro sec. das ist durchaus normal (je nach Hardware etc.). Das Verhältnis zum RLA ist auch der Benchmark geschuldet. Die Between Variante vereinfacht in erster Linie die Abfragen, was bei joins dem Query Optimizer Irrtümer erspart.

D*B

[Fuerchau]

Bei dieser ACTGRP-Kombination prüfe doch mal, ob der ODP der SQL's auch wirklich wiederverwendet wird und warum der absteigende Index nicht verwendet wurde.
Denn normalerweise sollte beides passieren.

[mwithake]

Ich habe die Abfrage noch einmal durch Visual Explain geschickt. Nun wird der absteigende Index genommen. Vielleicht brauchte der Optimizer etwas, bis er sich für den absteigenden Index entscheidet.

Der ODP wird anscheinend wiederverwendet, bei der Anzeige der offenen Dateien im Job bleiben die Dateien geöffnet und die relative Anzahl wird entsprechend hochgezählt. Oder wie prüfe ich das?