Performance sqlrpgle / strsql

[Robi]

Nachtrag:
der fetch im Rpg, aufgelöst als call sql...
braucht sowohl beim fetch first als auch beim den weiteren fetch next endlos lange
daher vermute ich, das auch ein optimize for 1 row nix hilft

[Fuerchau]

Éin kalkulierter Index hilft leider nicht wenn die Abfrage nicht auf "=" lautet.
Wenn du nicht mit "%xx%" arbeitest, kannst du ggf. den Index verwenden, wenn du auf
upper(Name) between VonName and BisName
abfragst.
VonName = 'JOK';
BisName = 'JOK' + *hival;
Aber auch hier gibts keine Garantie.

Hast du den "Optimize for" denn mal versucht?

[BenderD]

Nachtrag:
der fetch im Rpg, aufgelöst als call sql...
braucht sowohl beim fetch first als auch beim den weiteren fetch next endlos lange
daher vermute ich, das auch ein optimize for 1 row nix hilft

... hast Du da eine stored procedure mit Resultset gemacht? Schmeiß den Penner raus, das führt, ähnlich wie UDTFs zu einem optimize for all rows, der einen Hang zum full table scan hat - je mehr Tabellen gejoined werden, umso mehr tendiert das (fatalerweise) zum full table scan.
Wenn Du sicher bist, dass das resultiernde ResultSet klein ist, kannst Du auch versuchen in der stored procedure die hohen Selektivitäten vorzuziehen und temp tables zu verjoinen.

D*B

[Robi]

@D*B
Nee, nix Stored Procedure
Das Sql wird doch vom Compiler umgewandelt in einen call.
Und dieser call, der den 1. Fetch (fetch first from cursor01 into :f1, F2, ...)
dauert schon endlos.

@Baldur
ok, versuche mal auf between um zu stellen
Optimize n.n. versucht. mach ich auch gleich mal ...

anderer Test, 2 Selektions Kriterien, < 1 Sekunde interaktives sql, 2 Minuten 34 Sekunden SQLRPGLE.

Robi

[BenderD]

@D*B
Nee, nix Stored Procedure
Das Sql wird doch vom Compiler umgewandelt in einen call.
Und dieser call, der den 1. Fetch (fetch first from cursor01 into :f1, F2, ...)
dauert schon endlos.

Robi

... aus dem interaktiven SQL erfolgt hier auch nicht viel was anderes. Die lange Dauer für den ersten fetch könnte eben gerade auf einen full table scan hindeuten.
Die join order könnte man über die QAQQINI forcieren, würde ich aber normal nicht empfehlen. In jedem Fall würde ich einen order by machen, falls keiner da ist, das kann den Query Optimizer auch in eine Richtung schieben.

D*B

[B.Hauser]

Es gibt schon einen Unterschied zwischen STRSQL und statischem embedded SQL und zwar ist es das Optimierungsziel. Alle dynamsichen SQL-Statements (damit auch Abfragen aus STRSQL) werden per Default mit dem Optimierungsziel *FIRSTIO (der erste Datenblock muss so schnell wie möglich zurückgebracht werden). Statisches SQL wird per default mit Optimierungsziel *ALLIO optimiert, d.h. das komplette Ergenis muss so schnell wie möglich zurückgebracht werden.

Normalerweise hat das Optimierungsziel wenig Einfluss, kann aber genau in dem Moment wo sich der Optimizer zwischen Table Scan und halb-optimalem Index-Zugriff entscheidend sein.
Bei Dir ist genau diese Situation eingetreten.

Das Optimizerungsziel kann über die OPTIMIZE FOR X ROW-Anweisung beeinflusst weden.
Wird X durch eine kleine Zahl ersetzt, wird Optimierungsziel *FIRSTIO verwendet. Wird X durch eine sehr große Zahl oder ALL ersetzt wird Optimierungziel *ALLIO verwendet.

Birgitta

[Fuerchau]

Wobei ich diesem "Optimize for" nicht soi ganz traue, da ich trotz vieler Versuche selten einen Effekt erzielen konnte.

[Robi]

@D*B
alle fetch sind langsam, der erste ist definitiv nicht der 'schuldige'

@Baldur und Birgitta
also der optimize ist ja schnell eingebaut gewesen
for 9 rows keine Verbesserung
for 1 rows keine Verbesserung
das ist echt krank!

Ich glaube das ist eher langsamer geworden!

[Robi]

Warscheinliche Ursache:
DECLARE C1 DYNAMIC SCROLL CURSOR FOR SE_FLD1

statt
DECLARE C1 SCROLL CURSOR FOR SE_FLD1

jetzt ist die performance ok

Danke Euch allen

Robi

[BenderD]

ersteres erlaubt keine temporäre Kopie, was den Geschwindigkeitsunterschied erklärt.

D*B

[Fuerchau]

Auch stellt sich die Frage, warum einen Scroll-Cursor.
Das kann man doch mittels Subfile besser lösen.

Aber schön, dass du es doch selber gefunden hast.
Im STRSQL->F13 gibts hierzu die EInstellung "Datenaktualisierung" und "Datenkopie".
Schau dir dann mal deine Abfrage mit *ALWAYS an...

[Fuerchau]

Ich glaube da ist nur die Umsetzung des Compilers in eine "CALL SQLROUTE"-Anweisung gemeint.
Ohne den DB-Monitor wirst du da wohl nicht rumkommen.
Probier doch mal den "optimize for 1 rows" erst mal aus.