[53350] in SAPr3-news
Re: Performance-Problem
daemon@ATHENA.MIT.EDU (Christian Knappke)
Fri Feb 11 05:10:11 2005
To: sapr3-news@mit.edu
Date: Fri, 11 Feb 2005 10:06:56 +0000 (UTC)
From: Christian Knappke <chknews@gmx.net>
Message-ID: <Xns95FA71106648Cnnsshiqqcuusnqfigmxn@10.16.7.20>
From the keyboard of Jens Hoetger <Jens.Hoetger@de.bosch.com>:
> Hallo,
>
> wir haben bei einer (eigenentwickelten) Anwendung erhebliche
> Performance-Probleme. Das Select-Statement liest bereits "nur"
> die benötigten Felder eines Views, beteiligte Tabellen sind MKPF
> und MSEG. Der Execution Plan vom Oracle (Version 9...) sieht
> eigentlich nicht so schlecht aus:
> SQL Statement
> SELECT
> "MANDT" , "MBLNR" , "MATNR" , "WERKS" , "LGORT" , "BWART" ,
> "ERFMG"
> , "LGPLA" , "LGNUM" ,
> "LGTYP" , "BUDAT" , "ERFME"
> FROM
> "/RB04/YL4_V_MKPF"
> WHERE
> "MANDT" = :A0 AND "MATNR" IN ( :A1 , ..., :A64) AND "WERKS" =
> :A65 AND "BUDAT" >= :A66 AND "BUDAT" <= :A67 AND "LGORT" =
> :A68 AND (
> "BWART" = :A69 OR "BWART" = :A70
> ) AND "LGPLA" = :A71
>
> Execution Plan
> SELECT STATEMENT ( Estimated Costs = 1 , Estimated #Rows = 1 )
> FILTER
> NESTED LOOPS
> INLIST ITERATOR
> TABLE ACCESS BY INDEX ROWID MSEG
> INDEX RANGE SCAN MSEG~M
> TABLE ACCESS BY INDEX ROWID MKPF
> INDEX UNIQUE SCAN MKPF~0
>
> Das Problem scheint der Zugriff auf MSEG zu sein. Die Verwendung
> des Index MSEG~M ist nach meiner Einschaetzung (den CBO mal
> aussen vor) auch in Ordnung, der CBO liegt da wohl richtig. Die
> Tabelle enthaelt ca. 18 Mio Datensaetze, was zugegebenermassen
> nicht wenig ist, was sich aber nicht mal eben aendern laesst.
>
> Was mich wundert, sind die lahmen Zugriffszeiten:
> Duration Objectname Oper Rec RC Statement
> 1.416 /X/YL4_V_X PREPARE 0 0 SELECT WHERE "MANDT"
> ...
> 18 /X/YL4_V_X OPEN 0 0 SELECT WHERE "MANDT"
> ...
> 369951521 /X/YL4_V_X FETCH 677 0
> 442593250 /X/YL4_V_X FETCH 677 0
> 137638795 /X/YL4_V_X FETCH 677 0
> 44856.511 /X/YL4_V_X FETCH 205 1403
>
> Ein Fetch liest soweit ich weiss maximal 32KB Daten. Die
> benoetigten Zeiten dafuer sind enorm, ich verstehe nicht, warum
> das so lange dauert.
Rund 1/2 Sekunde pro row ist in der Tat enorm...
> Den Index MSEG~M habe ich neu erzeugt, da
> die Storage Quality bei 55% lag, aber das hat letzten Endes so
> gut wie nichts gebracht.
Das tut's auch nur selten...
> Die Hardware ist eine IBM Regatta
> irgendwas.
>
> Hat jemand einen Tipp oder eine Idee (Reorganisation der
> MSEG-Tabelle bzw. des Tablespaces mal ausgenommen)?
Hmm, mir fallen verschiedene Richtungen ein in denen weiter
geforscht werden könnte:
Ist das ABAP-Statement ein SELECT ... FOR ALL ENTRIES ...?
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".
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).
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?
Wieviel % der rows in MSEG findet die DB mit den 64 MATNRn, die Du
im Statement angibst?
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.
HTH
Christian
--
#include <std_disclaimer.h>
/* The opinions stated above are my own and not
necessarily those of my employer. */
