Re: Seltsame Performance von In-Clause Select

Geschrieben von Markus am September 30, 2002 um 14:27:

Als Antwort auf Re: Seltsame Performance von In-Clause Select geschrieben von Axel Pürner on September 26, 2002 um 16:23:

das ganze wurde aus einer anwendung (R/3) heraus abgesetzt, dort wird aber nach einem bestimmten konfigurationsparameter ein split in mehrere selects gemacht (hier bei 10), die 35 wurden also in 3 mal 10er und ein 5er gestaffelt.
fakt ist daß die 4er und 6er weniger gechachet sind als die 5er weil dieses insgesamt 15000 ausgeführt wurde, die anderen nur ein paar mal zum test.
Wir haben die neuesten DB2 Patches eingespielt(hat nix geholfen) und schliesslich den runstat nicht von bmc sondern mit ibm-runstat gemacht. daraufhin war das problem verschwunden.
kann jemand erraten wieso ? nur interessehalber...

: Hi Markus,

: zu 35 fällt mir nichts ein. Ist die Performance regelmäßig mit 35 schlecht? Es können ja sonstige zufällige Störungen durch Utilities oder andere Programme aufgetreten sein.
: Da es dynamisches SQL ist, könnte man vielleicht mit dem Workstation Online Monitor (von IBM) in den Statement Cache sehen, vorausgesetzt der entsprechende Trace läuft mit. Dann würden auch die Ausführungsstatistiken wie Anzahl Getpages, Anzahl I/Os etc. angezeigt. Denkbar wäre auch, die Selects mit 34 und 36 Elemente sind schon gecachet, der mit 35 noch nicht. Wenn hier ein echtes Problem vorliegt, läßt sich das sicher herausfinden, aber der Aufwand ist etwas größer und müßte von einem DB2-Systemer durchgeführt werden.

: MfG

: Axel Pürner

Antworten:

Re: Seltsame Performance von In-Clause Select Axel Pürner 10:33 06.10.2002 (0)

Schreibe eine Antwort

Name:
E-Mail:

Thema:

Kommentar:
: Hi : das ganze wurde aus einer anwendung (R/3) heraus abgesetzt, dort wird aber nach einem bestimmten konfigurationsparameter ein split in mehrere selects gemacht (hier bei 10), die 35 wurden also in 3 mal 10er und ein 5er gestaffelt. : fakt ist daß die 4er und 6er weniger gechachet sind als die 5er weil dieses insgesamt 15000 ausgeführt wurde, die anderen nur ein paar mal zum test. : Wir haben die neuesten DB2 Patches eingespielt(hat nix geholfen) und schliesslich den runstat nicht von bmc sondern mit ibm-runstat gemacht. daraufhin war das problem verschwunden. : kann jemand erraten wieso ? nur interessehalber... : : Hi Markus, : : zu 35 fällt mir nichts ein. Ist die Performance regelmäßig mit 35 schlecht? Es können ja sonstige zufällige Störungen durch Utilities oder andere Programme aufgetreten sein. : : Da es dynamisches SQL ist, könnte man vielleicht mit dem Workstation Online Monitor (von IBM) in den Statement Cache sehen, vorausgesetzt der entsprechende Trace läuft mit. Dann würden auch die Ausführungsstatistiken wie Anzahl Getpages, Anzahl I/Os etc. angezeigt. Denkbar wäre auch, die Selects mit 34 und 36 Elemente sind schon gecachet, der mit 35 noch nicht. Wenn hier ein echtes Problem vorliegt, läßt sich das sicher herausfinden, aber der Aufwand ist etwas größer und müßte von einem DB2-Systemer durchgeführt werden. : : MfG : : Axel Pürner

Optionale Link URL:
Link Titel:
Optionale Image URL:

[ Antworten ] [ Forum ]