[53379] in SAPr3-news
Re: Performance-Problem
daemon@ATHENA.MIT.EDU (Jens Hoetger)
Mon Feb 14 06:52:10 2005
To: sapr3-news@mit.edu
Date: Mon, 14 Feb 2005 12:51:15 +0100
From: Jens Hoetger <Jens.Hoetger@de.bosch.com>
Message-ID: <q61111d6i13jeq2642okf1306keonga68i@4ax.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. 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,
>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).
>
>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 %).
>
>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.
Die Haelfte der benotigten Felder findet sich nicht in einem Index.
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.
--
Jens Hoetger
-> http://www.scribblepapers.de.vu
