[53400] in SAPr3-news
Re: Performance-Problem
daemon@ATHENA.MIT.EDU (Christian Knappke)
Tue Feb 15 04:10:11 2005
To: sapr3-news@mit.edu
Date: Tue, 15 Feb 2005 09:05:21 +0000 (UTC)
From: Christian Knappke <chknews@gmx.net>
Message-ID: <Xns95FE66A04338Dnnsshiqqcuusnqfigmxn@10.16.7.20>
From the keyboard of Jens Hoetger <Jens.Hoetger@de.bosch.com>:
> On Fri, 11 Feb 2005 10:06:56 +0000 (UTC), Christian Knappke
> <chknews@gmx.net> wrote:
>
> <snip>
>>
>>Ist das ABAP-Statement ein SELECT ... FOR ALL ENTRIES ...?
> In dem Testprogramm ist ein SELECT ... WHERE <feld> IN
> <tabelle>, was wohl auf das gleiche hinauslaeuft.
Nein. Das ist nicht das gleiche, da das DBI diese Statements ggfs.
unterschiedlich umsetzt und unterschiedliche Parameter "ziehen".
> Allerdings ist
> das im "Original"-Programm so nicht drin, dort wird etliche Male
> ein einzelnes Set von Datensaetzen gelesen (ohne
> Selektionstabelle, also statt einem Zugriff viele einzelne
> Zugriffe). Fuer das Testprogramm hatte ich das per
> Selektionstabelle versucht, was letzten Endes aber auch nicht
> den Durchbruch gebracht hat.
>>Die IN-Liste ist relativ lang (besonders für Orrible 9). Du
>>kannst das für FOR-ALL-ENTRIES-Statements mit dem
>>Profilparameter rsdb/ {min|max}_in_blocking_factor einstellen.
>>Der steht zweckmäßig auf kleinen Werten (5 ... 20). Die
>>aktuellen Werte findest Du im dev_*-Trace eines beliebigen DIA-
>>oder BKG-WPs ziemlich am Anfang, auch wenn der Profilparameter
>>noch nicht gesetzt ist. RSPARAM zeigt Dir evtl. nur -1, was
>>heißt "Kernel-Default".
> Da werden die Parameter 2x aufgelistet:
> B Mon Feb 14 01:17:26 2005
> B dbtran INFO (init_connection '<DEFAULT>' [ORACLE:46D.00]):
> B max_blocking_factor = 5, max_in_blocking_factor
> =1000, B min_blocking_factor = 5, min_in_blocking_factor
> = 10,
Ich sehe hier sowohl max_in_blocking_factor als auch
min_in_blocking_factor nur einmal aufgelistet. Die gehören bei
ORA9 beide auf 5..10, keinesfalls auf 1000. Das ist mit aktuellen
Kernel-Patches AFAIK auch schon korrigiert.
>>Leider lässt Du Dich nicht näher über die View-Definition aus,
>>evtl. spielen weitere Selektionen im View noch eine Rolle. Auch
>>kann ich momentan nicht nachsehen, wie der Index aussieht
>>(abgesehen davon, dass das SAP-Release im Dunkel bleibt).
> Der Join sieht folgendermassen aus:
> Tabelle Feldname =Tabelle Feldname
> MSEG MANDT =MKPF MANDT
> MSEG MBLNR =MKPF MBLNR
> MSEG MJAHR =MKPF MJAHR
> SAP-Release ist 4.6c (Support Packages bis 47).
Hmm, das ist allerdings nur ein Teil der View-Definition, nämlich
die Join-Bedingung. Die ist in Ordnung, es wird über die ersten
drei Felder, bzw. bei MKPF über den Primärschlüssel ge-join-t.
>>Du liest 2236 rows. Dazu ist evtl. eine Menge I/O nötig und das
>>braucht Zeit. Läuft es beim zweiten Mal deutlich schneller?
> Es laeuft zwar schneller, wg. DB-Puffer, aber die Zeiten sind
> immer noch jenseits von gut und boese.
>>Wieviel % der rows in MSEG findet die DB mit den 64 MATNRn, die
>>Du im Statement angibst?
> Die Tabelle hat 18,8 Mio Saetze, und die Selektion auf 64
> Materialnummern ergibt eine Treffermenge von 484 Saetzen (0,002
> %).
IMO ist die IN-Liste zu lang. Teil' Dein Statement mal in kleinere
Häppchen: sezt die o.g. Parameter richtig und schreib' das ABAP-
Statement um in ein SELECT ... FOR ALL ENTRIES.
>>MSEG ist eine Clustertabelle. Überleg mal, ob Du die gewünschten
>>Daten nicht günstiger über eine der vielen Indextabellen zur
>>MSEG beschaffen kannst. Dazu befrag' mal die MM-Experten.
Hab' jetzt mal nachgesehen. MSEG ist hier transparent.
> Die Haelfte der benotigten Felder findet sich nicht in einem
> Index.
Ich meinte keinen Datenbank-Index, sondern Index-Tabellen. Das
sind Tabellen, die bestimmte Ausschnitte der in solchen
Monstertabellen wie MSEG enthaltenen Daten redundant bereithalten.
Aus diesen kann man ggfs. viel eleganter seine gewünschten
Informationen beziehen. Wie gesagt, frag Deine MM-Experten.
> Es gibt noch einen Ansatzpunkt, und zwar mit dem Oracle event
> 10062, wodurch man erweiterte Trace-Details kriegt. Muessen wir
> mal probieren... mal sehen, was dabei rauskommt.
HTH
Christian
--
#include <std_disclaimer.h>
/* The opinions stated above are my own and not
necessarily those of my employer. */
