SQL Performance

[Dirschl]

@BenderD
Aktuelle Messung: ca. 1 sec

Die Zeiten schwanken etwas, sind aber im Vergleich zu gestern aufgrund der Umbauten wesentlich schneller.

Im Debug sehe ich keinen Zugriffsplan - vom DBMON habe ich leider keine Ahnung.

Die Selektionsfelder befinden sich bei dieser Abfrage alle in der Datei GIDPF300 - lt. Debug verwendet er 2 Indexe.

[Fuerchau]

Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.

[Dirschl]

Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.

Ist richtig!

Diverse Schwankungen die ich bei den Messungen noch festgestellt habe, werde ich jetzt einfach mal ignorieren und als gegeben hinnehmen (die SQL-Performance werde ich wohl nie kapieren - obwohl ich mittlerweile auf dieser Maschine sehr viel mit SQL arbeite - aber ich muss nicht alles kapieren )

Besten Dank für Eure Hilfe!

[Fuerchau]

Schwankungen resultieren ggf. aus anderen Job's, oder hast du die Maschine für dich alleine ?

[Dirschl]

Ist mir schon klar, dass andere Job's die Schwankungen theoretisch verursachen können.

ABER: Die Maschinie "fadisiert" sich üblicherweise - und Schwankungen um das 3-5 -fache - bei gleicher Auslastung - lassen sich nicht durch andere Job's erklären - und schon gar nicht nach 18:00 Uhr!

Aber was soll's - ist halt so (habe auch schon mal festgestellt, dass nach einem Betriebssystemwechsel die SQL-Performance zusammengebrochen ist - hat plötzlich 10-15 mal solange gedauert wie vorher!)

Anderes Problem:

Kann ich eigentlich einen Index über ein Teilfeld legen (z.B: Index über Substr(qpr100, 4, 16).

[BenderD]

Hallo,

entweder CHGJOB QRYTIMLMT(0) für interaktive Jobs, oder strdbg für den Job (bei Batchjobs vorher STRSRVJOB) bringt diagnostic messages in das Joblog über Verwendung von Zugriffspfaden, warum bestimmte nicht verwendet werden, ob der Optimizer fertig geworden ist, etc. das ist eigentlich immer der Einstieg zur Analyse, wenn man berweits weiß, wo es klemmt.
Weiß man noch nix, dann STRDBMON mit DETAIL(*ALL) für alle Jobs (vorsicht immenses Datenvolumen) und dann ... muß man doch ein wenig Wissen und Erfahrung haben, damit man findet, was man sucht - et voila in wenigen Stunden weiß man, wo es klemmt (zuweilen).

Nach OS Wechsel (und nach PTFs) klebst seit V5R2 teils erheblich, wg. der famosen neuen Query Engine, die leider Häppchenweise als Beta auf die Büchse kommt...

Dieter Bender

PS: Wenns wieder mal Ausreißer gibt, mehr Infos bitte, das spart Zeit

@BenderD
Aktuelle Messung: ca. 1 sec

Die Zeiten schwanken etwas, sind aber im Vergleich zu gestern aufgrund der Umbauten wesentlich schneller.

Im Debug sehe ich keinen Zugriffsplan - vom DBMON habe ich leider keine Ahnung.

Die Selektionsfelder befinden sich bei dieser Abfrage alle in der Datei GIDPF300 - lt. Debug verwendet er 2 Indexe.

[Dirschl]

PS: Wenns wieder mal Ausreißer gibt, mehr Infos bitte, das spart Zeit

Werde es beim nächsten Mal berücksichtigen - nochmals besten Dank für die Hilfe!