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

[andreaspr@aon.at]

Hallo,

sicher dass das SQL Statement bei der Änderung des Limits !=200 genau das gleiche ist (bis auf das Limit)?
Keine andere Sortierung oder der gleichen?
Das ist schon sein sehr ungewöhnliches verhalten wenn es so dramatisch am Limit liegt.

STRSQL und der Navigator haben sowieso ihre eigene Limits die da überschrieben werden.
Man glaubt es wurde alles gelesen, dabei werden die restlichen Sätze erst beim hinunter scrollen gelesen.

Hast du schon probiert das ganze mit dem DB-Monitor zu analysieren?

lg Andreas

[BenderD]

... die Angaben sind ein wenig konfus (das SQL sieht verkürzt... dann doch ganz anders aus...). Sieht für mich nach einem kaputten package aus. Ich würde erst einen recreate des Programms versuchen und ansonsten Software defect reklamieren.

D*B

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