[53341] in SAPr3-news
Re: Performance-Problem
daemon@ATHENA.MIT.EDU (Volker Gueldenpfennig)
Thu Feb 10 16:44:40 2005
To: sapr3-news@mit.edu
Date: 10 Feb 2005 13:44:32 -0800
From: volker_remove_this@4soi.de (Volker Gueldenpfennig)
Message-ID: <be90f755.0502101344.78dbf4d7@posting.google.com>
Hi Jens,
> 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
...
>
> 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
die Where-Bedingung scheint auf den ersten Blick selektiv zu sein, da
nur 2000-3000 Sätze zurückkommen. Ich würde aber mal einen count(*)
auf die MSEG mit der dann noch übrig bleibenden Where-Bedingung
machen. Ich befürchte nämlich, dass der grösste Teil über das
Intervall BUDAT auf der MKPF selektiert wird, was dazu führt, dass
zuerst die MSEG, dann der Join, dann die MKPF gelesen werden muss, um
dann erst festzustellen, dass der Satz doch in die Tonne muss :-(((
Gruß
Volker
http://www.easymarketplace.de
