SQL Ersatz für SETGT/READE Kombi

[BenderD]

@Fuerchau Ein absteigender Index hat keine Änderungen gebracht.
@BenderD Was muss mit dem Feld gemacht werden?

... dann holt man sich die Sätze mit:
SELECT wert
FROM Tabelle
WHERE key=:yKey
AND :yDatum between gilt_ab and gilt_bis
das sollte schneller sein und macht vor allem das Leben einfacher, da sich das im View Layer abbilden lässt.
Beim neuesten schreibt man dann in gilt_bis Highval rein.
D*B

[mwithake]

Das muss wohl am SQL-Overhead liegen.

@Fuerchau: Die Werte sind schon für 100.000 Aufrufe (wie in der ersten Frage angegeben). Das "Into" hatte ich zur Übersicht rausgenommen, die Aufrufe fanden mit SELECT INTO statt. Visual Explain zeigt auch an, das der absteigende Index nicht genommen wird.

@Bender: Die Abfrage mit gültig_bis und BETWEEN dauerte (ohne Index Optimierung und View) etwas länger als die beiden anderen. Vielleicht sind die Anzahl der Sätze, die derzeit in der Tabelle vorhanden sind, auch zu gering um einen Unterschied festzustellen.

Ich hatte die Frage einfach mal in dem Raum gestellt, da ich immer wieder auf diese Art der Abfrage stoße. Vielleicht hätte es ja einen eleganteren SQL Weg gegeben, dieses Problem zu lösen (RPG hat ja auch Operationen für diesen Art des Zugriffs).
Besonders in SQL-Abfrage, die einen Wert aus der "Gültig_AB" Tabelle dazu holen müssen, wäre es interessant. Die Abfrage ist dann sehr kompliziert, Select mit Unterselect auf "Gültig_AB" Tabelle und darauf wieder Unterselect für die MAX() Funktion. Mehrere 1000 Sätze kommen dann schnell zustande, welche die Unterabfrage dann wieder auslösen und den Geschwindigkeitsunterschied bemerkbar machen.

Sicherlich kann man die Funktion auch mit Stored-Procedure implementieren (mit allen möglichen Optimierung, Deterministic etc). Aber hier wäre der Optimizer wieder ein bisschen außen vor, falls es doch mal diese Art der Abfragen optimieren könnte. Und um die Abfrage in der Procedure schnell zu bekommen müssten man wieder auf RPG zurückgreifen, was wir in unsere Java-Umgebung nicht mehr so gerne möchten.

[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?