SQL in RPG dauert ewig

[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