Laufzeitoptimierung

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
6 Beiträge • Seite 1 von 1
6 Beiträge Seite 1 von 1

Laufzeitoptimierung

Beitrag von ABAP_DEV (ForumUser / 7 / 0 / 0 ) »
Hallo Zusammen,

ich hätte gern Hilfe bei der Optimierung der Laufzeit bei dieser Anweisung.

Code: Alles auswählen.

    SELECT * FROM wbrk INTO TABLE gt_wbrk
        FOR ALL ENTRIES IN gt_knvv
        WHERE wdtyp = 'B'
        AND valdtd > p_stichd
        AND ( vkorg = gt_knvv-vkorg
         OR ( vkorg = gc_vkorg_init AND ekorg = gt_knvv-vkorg ) )
        AND kunre = gt_knvv-kunnr
        AND lifre IN so_lifre
        AND vtweg = gt_knvv-vtweg
        AND spart = gt_knvv-spart
        AND rfbsk NOT IN ('R','D')
        AND /zrb/belegtyp IN (' ','1')
        AND wrart IN lt_wrart "('ZR', 'IB', 'FORD' 'ZA').
        AND wfdat <= p_stichd
        %_HINTS DB6 '<IXSCAN TABLE="WBRK" SAP_INDEX="WBRK~Z05"/>)'.
Die Tabelle WBRK hat je nach VKORG ca. 1,5 Mio und die Itab GT_KNVV kann mind. 100 Zeilen haben. Momentan läuft das bis zu mehrere Stunden.

Ich habe versucht den Select anzupassen, leider läuft das immer noch langsam. Das habe ich zuletzt probiert:

Code: Alles auswählen.

SELECT kunre vkorg vtweg spart lifre ekorg bukrs valdtd brtwr /zrb/kzwi1
       valdt waerl /zrb/kein_delk lfgru bldat brtwrd /zrb/kzwi1d mwsbk /zrb/kzwi2
       /zrb/kzwi2d /zrb/at_steu_sum /zrb/at_wert_sum netwr gskto gsktod lftyp
        FROM wbrk INTO CORRESPONDING FIELDS OF TABLE gt_wbrk
        WHERE wdtyp = 'B'
        AND valdtd > p_stichd
        AND ( vkorg = s_vkorg
         OR ( vkorg = gc_vkorg_init AND ekorg = s_vkorg ) )
        AND kunre = s_kunnr
        AND lifre IN so_lifre
        AND vtweg = s_vtweg
        "AND spart = gt_knvv-spart
        AND rfbsk NOT IN ('R','D')
        AND /zrb/belegtyp IN (' ','1')
        AND wrart IN lt_wrart
        AND wfdat <= p_stichd
        %_HINTS DB6 '<IXSCAN TABLE="WBRK" SAP_INDEX="WBRK~Z05"/>)'.

        LOOP AT gt_knvv ASSIGNING FIELD-SYMBOL(<ls_knvv>).
          READ TABLE gt_wbrk WITH KEY vkorg = <ls_knvv>-vkorg kunre = <ls_knvv>-kunnr
          vtweg = <ls_knvv>-vtweg TRANSPORTING NO FIELDS.
          IF sy-subrc <> 0.
            DELETE gt_wbrk WHERE vkorg = <ls_knvv>-vkorg AND kunre = <ls_knvv>-kunnr
            AND vtweg = <ls_knvv>-vtweg .
           ENDIF.

        ENDLOOP.
Hat jemand einen Vorschlag, wie ich das lösen kann?

Ich danke euch im Voraus
Marcel

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Laufzeitoptimierung

Beitrag von Lukas Sanders (ForumUser / 64 / 7 / 33 ) »
Hallo Marcel,

"NOT IN" als Kriterium ist in den meisten Fällen problematisch. Eventuell wird es etwas schneller, wenn für RFBSK die erlaubten Werte angegeben werden und nicht die ausgeschlossenen.

Auch habe ich die Erfahrung gemacht, dass ">=" und "<=" in Verbindung mit Datumsfeldern die Performance extrem beeinträchtigt. Das wird sich vermutlich hier nicht ändern lassen, aber eventuell ist eine der beiden Prüfungen für WFDAT und VALDTD verzichtbar.

Woher stammen die Einträge in der GT_KNVV? Besteht die Möglichkeit, hier vielleicht einen Join einzubauen statt FOR ALL ENTRIES oder dem anschließenden LOOP?

Gruß
Lukas

Re: Laufzeitoptimierung

Beitrag von ABAP_DEV (ForumUser / 7 / 0 / 0 ) »
Hi Lukas,

danke für deine Antwort. Ich habe den Select teilweise angepasst. Das Programm ist schneller als zuvor.
Die Einträge in der GT_KNVV stammen aus der logischen DB.

SELECT wbrk~kunre wbrk~vkorg wbrk~vtweg wbrk~spart wbrk~lifre wbrk~ekorg wbrk~bukrs wbrk~valdtd
wbrk~brtwr wbrk~/zrb/kzwi1 wbrk~valdt wbrk~waerl wbrk~/zrb/kein_delk wbrk~lfgru wbrk~bldat
wbrk~brtwrd wbrk~/zrb/kzwi1d wbrk~mwsbk wbrk~/zrb/kzwi2 wbrk~/zrb/kzwi2d wbrk~/zrb/at_steu_sum
wbrk~/zrb/at_wert_sum wbrk~netwr wbrk~gskto wbrk~gsktod wbrk~lftyp
FROM wbrk INNER JOIN knvv ON wbrk~kunre = knvv~kunnr
INTO CORRESPONDING FIELDS OF TABLE gt_wbrk
WHERE wdtyp = 'B'
AND valdtd > p_stichd
AND ( wbrk~vkorg IN s_vkorg
and ( knvv~vkorg IN s_vkorg )
OR ( wbrk~vkorg = gc_vkorg_init AND ekorg IN s_vkorg ) )
"AND kunre = knvv~kunnr
AND lifre IN so_lifre
AND wbrk~vtweg IN s_vtweg
AND rfbsk NOT IN ('R','D')
AND /zrb/belegtyp IN (' ','1')
AND wrart IN lt_wrart
AND wfdat <= p_stichd
%_HINTS DB6 '<IXSCAN TABLE="WBRK" SAP_INDEX="WBRK~Z05"/>)'.

Leider habe ich jetzt ein neues Problem: TSV_TNEW_PAGE_ALLOC_FAILED

Fehleranalyse:
Die interne Tabelle "???" konnte nicht mehr erweitert werden. Um die
Fehlerbehandlung zu ermöglichen, mußte die Tabelle noch vor der
Aufbereitung dieses Protokolls gelöscht werden. Dies hat zur Folge, dass
die Tabelle weiter unten oder, wenn von hier aus in den ABAP-Debugger
gesprungen wird, mit 0 Zeilen angezeigt wird.

Zum Zeitpunkt des Abbruchs wurden für die betroffene interne Tabelle die
folgenden Kenndaten ermittelt:

Speicherort: Session memory
Zeilenbreite: 16468
Zeilenanzahl: 0
Allokierte Zeilen: 561785
Neu angeforderte Zeilen: 1 (in 561784 Blöcken)

Hast du sowas schon mal gehabt?

Danke nochmal

VG
Marcel

Re: Laufzeitoptimierung

Beitrag von gtoXX (Specialist / 185 / 34 / 31 ) »
Hallo Marcel,

zu dem Fehler : Ja das ist normal wenn man zu riesig selektiert. Das System reizt schlichtweg den maximal zugewiesenen Arbeitsspeicher aus. Hier wäre zu prüfen ob die internen Tabellen nicht einfach zu viele Felder beinhalten.

Also erstmal ist die Verwendung von Datenbank-Hints schon kritisch zu sehen.
Desweiteren : Selektieren und anschliessend löschen ist immer die schlechteste Wahl.
Dazu ist der Join nicht ganz sauber gemacht WBRK und KNVV haben die VKORG und den VTWEG gemeinsam. Also auch den Join darauf beziehen.

ekorg IN s_vkorg --- ist ganz furchtbares Design. Das Ergebnis passt nämlich nur, wenn die zufällig gleich eingestellt ( benamt ) sind. Also korrekterweise saubere Parameter benutzen.

Wozu wird die KNVV überhaupt gelesen ? Der Select holt alle Felder aus der WBRK. Der Join scheint überhaupt nicht nötig. Die Selektionsparameter, die die KNVV gefüllt haben, können 1:1 verwendet werden ( KUNNR, VTWEG,VKORG ).

Ich würde das Programm-Design einer ernsthaften Architektur-Prüfung unterziehen.

Es gibt einen Standard-Index WBRK~001 auf WFDAT RFBSK daher mal diese beiden Felder auch an den Anfang der Where-Bedinung stellen.

Folgende Benutzer bedankten sich beim Autor gtoXX für den Beitrag:
DeathAndPain

"Code lügt nicht ^^"

Re: Laufzeitoptimierung

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Verwende PACKAGE-SIZE
Das macht die Selektion nicht schneller, reduziert aber die Datenmenge, die in den Speicher geladen wird.

Re: Laufzeitoptimierung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
gtoXX, im wesentlichen stimme ich Deiner Einschätzugn zu. Dennoch einige Anmerkungen:
gtoXX hat geschrieben:
31.07.2020 14:42
Also erstmal ist die Verwendung von Datenbank-Hints schon kritisch zu sehen.
Kann bei so einem konfusen SELECT aber durchaus Sinn machen, wenn man als Programmierer genau beurteilen kann, über welchen Index die Datenbank einsteigen sollte. Angesichts der Laufzeit ist freilich zu vermuten, dass das hier nicht der Fall ist.
gtoXX hat geschrieben:
31.07.2020 14:42
Dazu ist der Join nicht ganz sauber gemacht WBRK und KNVV haben die VKORG und den VTWEG gemeinsam. Also auch den Join darauf beziehen.
Allein das reicht ja schon als Erklärung aus, da es dadurch Kreuzprodukte gibt und sich die Ergebnismenge folglich vervielfacht!
gtoXX hat geschrieben:
31.07.2020 14:42
Es gibt einen Standard-Index WBRK~001 auf WFDAT RFBSK daher mal diese beiden Felder auch an den Anfang der Where-Bedinung stellen.
Das ist egal; der Datenbank-Optimierer sucht sich anhand der angegebenen Selektionskriterien den besten Index heraus. Die Reihenfolge, in der die Kriterien angegeben werden, spielt keine Rolle. RFBSK würde er eh nicht nutzen können, da auf WFDAT per Ungleichheit geprüft wird, so dass die Indexnutzung dort schon enden würde und das zweite Feld egal wäre.

Aber: er hat ja über seinen Datenbank-Hint fest vorgegeben, mit welchem Index die Datenbank suchen soll. Dabei handelt es sich um einen Z-Index, also einen selbst angelegten, dessen Inhalt wir nicht kennen. Wer weiß, was da drinsteht...

Seite 1 von 1

Vergleichbare Themen

17
Antw.
12991
Views
Laufzeitoptimierung: Tuning-Challenge - Part I
von black_adept » 25.05.2004 15:41 • Verfasst in Tips + Tricks & FAQs
1
Antw.
1406
Views
Tabellen durchscannnen - Laufzeitoptimierung Z_SCAN_TABLE
von jspranz » 17.03.2006 14:39 • Verfasst in ABAP® Core

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140