Performance-Pobleme SQL-Select - Jobaufrufstapel hängt bei QDBGETMQO

[berndl]

erstmal danke für die schnellen Antworten!

Das SQL ist genau identisch - inkl. Leerzeichen. Der Benutzer gibt die Suchkriterien jeweils ein und daraus wird das Select-Statement generiert.
Hab dar Programm aus einer anderen LIB kopiert, wo wir das Prolem nicht haben (andere Daten) -> gleiches Verhalten.
Was ist mit kaputten Package gemeint? Die Programme werden jeweils auf einem anderen System kompilliert (CRTSQLRPGI ...).
Der DB-Monitor (=SQL-Performance-Monitor?) zeigt mir keine hilfreichen Informationen. Dort sehe ich lediglich, dass die Fetch-Opreration "FETCH SQL_EXTRACT INTO DESCRIPTOR : H" eine Runtime von 280.270424 Sekunden hat. Die gleiche Operation für die anderen Row-Limite aber nur 0.000104 Sekunden. Beide Male gibt's die gleiche Ergebnismenge: 0 Treffer!
Die detaillierte Auswertung mit VisualExplain sagt mir darüber hinaus nichts mehr - da fehlt das Detailwissen.

[Fuerchau]

Das mit dem Limit kann schon mal sein, da SQL intern blockt.
Da kann schon mal 1 Satz mehr zu einem 2. Block und somit zu einem erneuten DB-Zugriff führen.
Der DBGETMQ erstellt temporär eine Ergebnistabelle (MaterializedQueryTable) was massiv auf fehlende Indizes hindeutet.
Wenn das mit einer anderen Daten-Lib läuft, ist dort die Datenmenge anders was zu anderen Optimierungszielen führt und somit zu anderem Verhalten.

Ggf. hilft ein "Optimize for firstio" (oder so ähnlich), was dann beim Weiterblättern nicht hilft.
Ich musste bei V7R1 schohn änliches feststellen.

[BenderD]

Was ist mit kaputten Package gemeint? Die Programme werden jeweils auf einem anderen System kompilliert (CRTSQLRPGI ...).

Das Package ist Teil des Programm Objektes, ich würde das möglichst mal auf dem Echtsystem erstellen, zumindest neu deployen.

[berndl]

okay, das klingt schon beruhigender - dachte das Q-DBG-ETMQO hat irgendwas mit Debug zu tun.
Dann deployen wir das Ganze nochmals und prüfen wieder die ganzen Indizes...
Danke, meld mich wieder nach der Indexanalyse

[berndl]

Nach Rücksprache mit IBM haben wir das Problem jetzt gelöst. Das Verhalten lag an einer Einstellungen im QAQQINI:
REOPTIMIZE_ACCESS_PLAN war bei uns auf *ONLY_REQUIRED gesetzt - diese Einstellung wurde von der "alten" Maschine übernommen und nicht hinterfragt. Seit der Wert auf *DEFAULT steht, ist auch die Performance für 200 Datensätze okay.
Danke für eure Hilfe.

[BenderD]

... das sind ganz grundsätzlich Einstellungen an denen niemals global gedreht werden sollte!!!