SQL in RPG dauert ewig

[Fuerchau]

Da stimme ich dir nur bedingt zu, meine Erfahrungen sind da andere.
Der Exists wird wohl etwas anders implementiert sein und bietet mir bei Verwendung eines Index bisher immer das beste Ergebnis.

Kritisch sehe ich auch diese Angaben
"1 Access path(s) used for bitmap processing of file CHTRNP."
Dies ist für kleinere Dateien lohnenswert, für größere wird es problematisch. Ursache könnte der order by sein.

Wahrscheinlich ist auch, dass der Sort entfallen kann, wenn für die Order by Felder ein Index vorhanden ist. Das hängt im Endeffekt auch vom gewünschten Ergebnis ab.
Ohne Index muss ja erst mal alles eingelesen und sortiert werden.

Was ACS/STRSQL angeht, so habe ich die Variante mit "optimize for 1 rows" auch schon probiert (in verschiedenen Releases), konnte aber bzgl. des Vergleichs zu STRSQL da auch nichts verbessern.
Da laut Trace auf der IBM i (PCSACC/400) der SQL nicht verändert wurde, kann es "optimize" einfach nicht sein, es muss noch eine andere, undokumentierte Funktion (ggf. CLI-Attribute) sein, die man außerhalb von CLI nicht erreichen kann.

Bei den "ALL ACCESS PATHS..." Nachrichten kann man per F1 prüfen, welcher Index denn im Endeffekt verwendet wurde. Dieser kann und muss nicht der günstigste gewesen sein sondern wurde als "geringstes Risiko" ausgewählt.

Beispiel "in":
Hier ist eine Or-Klausel im Spiel, die beim Zugriff zu mehreren Sätzen führen kann.
Existiert ein Index über OHDISC und ein weiterer über OHDLRC als auch über OHTRNP der betroffenen Tabellen?
Wenn nein sollte man da über einen Exist nachdenken und Indizes erstellen.

[B.Hauser]

Ich denke wir können jetzt noch lange herumphilosphieren, ohne die tatsächliche Umgebung zu kennen (Anzahl Datensätze, Zugriffswege, IBM i Release etc.) können wir nur im Dunkeln tappen.

Vielleicht noch eine Anmerkung:
Wenn ich die Abfrage richtig interpretiere wird zumindest an einer Stelle (DNPTRNL17) auf eine logische Datei zugegriffen.
Mit SQL sollte ausschließlich auf Tabellen/physische Dateien und Views zugegriffen werden.
Beim Zugriff auf eine logische Datei wird die Abfrage zunächst vom Query Optimizer umgeschrieben. Dabei wird das DDS der logischen analysiert und dann die Feld-Auswahl, Join-Anweisungen und SELECT/OMIT-Anweisungen ausgelesen. Im Anschluss daran wird die Abfrage basierend auf der physischen Datei und den DDS Informationen der logischen neu geschrieben.
Erst dann erfolgt die Optimierung. An dieser Stelle ist nicht mehr bekannt, dass ursprünglich eine logische Datei angegeben war.
Wenn der Zugriffsweg der logischen Datei in der Abfrage verwendet wird, ist das nichts weiter als Zufall.

[itec01]

Danke für die konstruktiven Antworten.
Ich baue nun das SQL auf das exists statement um, weil die OR Verknüpfung sicherlich nicht gut ist.
Das könnte schon das Problem gewesen sein. Echt blöd ist halt, dass sich RPG mal wieder anders verhält als der Rest. Ich gehe immer so vor, dass ich mir das SQL im Visualizer oder ACS Editor baue und auch auf Performance hin teste und dann ins RPG übertrage. Klar wird dann dort auch noch einmal ein Test gemacht, aber bei den vielen Selektionsauswahlen kann man nicht alle Kombinationen testen, das darf dann der User tun.
@Brigitta, ja das stimmt mit der logischen. Hier greift sich der Optimizer eh was er gerne hätte. Ist geändert.

[KingofKning]

Mit SQL sollte ausschließlich auf Tabellen/physische Dateien und Views zugegriffen werden.
Beim Zugriff auf eine logische Datei wird die Abfrage zunächst.....

Erinnert mich ein wenig an Deinen Artikel vor genau einem Jahr. Wobei mein Kleinhirn noch nicht den Unterschied zwischen LF und View erkannt hat. (Außer evtl. Schlüssel) Ist aber auch nicht so wichtig, da ich nur mit tausenden Datensätzen zu tuen habe und mit Kisten die schon > 10 Jahre sind viele auch älter 20 Jahre.
https://midrange.de/sql-indices-anst...ien-verwenden/

GG 3735

[Fuerchau]

LF = DDS-View (Select/Omit/Index, Joins)
View = SQL-View (Full-Select where, kein Index)
Index= SQL-Index (kann aber where enthalten und ist dann eher mit der LF vergleichbar)

RPG/LE wird grundsätzlich vom SQL als Batch interpretiert.
ACS/STRSQL eben als Dialog mit unbekannten, nicht öffentlichen, Zusatzeinstellungen.
Ggf. weiß die SQL-Engine, wer da was abfragt und optimiert dann anders.

Die Debugnachrichten unterscheiden sich da schon mal zwischen STRSQL oder embedded SQL.

[Andreas_Prouza]

Die Debugnachrichten liefern auch nicht alle Informationen die es für diese Abfrage gibt.
Dafür wäre ein Monitor sinnvoll.
Im RPG hast du z.B. die Möglichkeit mit SET OPTION bestimmte Einstellungen für den Kompiler vorzugeben.
Je nach Einstellungen (und davon gibt es einige), kann sich das verhalten ändern.
RPG hat seine Default-Einstellungen und der ACS/STRSQL & Co können ebenfalls ihre eigene Default-Einstellungen haben.
Den tatsächlichen Unterschied, kann man via Monitor vergleichen und dann sieht man woran es liegen könnte.

lg Andreas