Performance Problem

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
3 Beiträge • Seite 1 von 1
3 Beiträge Seite 1 von 1

Performance Problem

Beitrag von ChrissixD (ForumUser / 27 / 17 / 0 ) »
Hallo zusammen,
ich habe in meinem Programm ein Problem mit der Performance. Es läuft alles gut bis auf ein Select, aber ich weiß leider nicht was ich da besser machen könnte. Vielleicht habt ihr ja eine Idee :)

Code: Alles auswählen.

  select eina~relif up to 1 rows into wa-vix
   from eina
   inner join marc on marc~matnr = eina~matnr
   where marc~dismm = 'VI' and
    eina~lifnr = wa-parnr and
    eina~relif = 'X' and
    eina~loekz NE 'X'.
   endselect. 
Damit will ich überprüfen ob ein Lieferant (wa-parnr) bei einem Material Regellieferant (RELIF) ist, welches das Dispomerkmal (DISMM) 'VI' hat. Außerdem soll überprüft werden ob ein Löschkennzeichen gesetzt ist (LOEKZ). Das dauert sehr lange bei mehreren Lieferanten.
Gibt es vielleicht eine bessere/schnellere Möglichkeit das umzusetzen?

Danke und Gruß
Christian

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


Re: Performance Problem

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Ein Index auf MARC für Felder MATNR und DISMM könnte helfen.
Wenn ich das recht erinnere, ist auch die Abfrage auf Gleichheit besser, als auf ungleich (=> LOEKZ = SPACE).

Re: Performance Problem

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Also zunächst mal gefällt mir das UP TO 1 ROWS nicht. Warum schreibst Du nicht einfach SELECT SINGLE, anstatt eine Schleife mit nur einem Durchlauf aufzumachen?

Allerdings ist das nur eine kosmetische Anmerkung, die Dein Problem nicht lösen wird. Ich sehe die Gefahr, dass Du durch den JOIN halt viele Kreuzprodukte bekommst, da Du von keiner der beteiligten Tabellen den vollständigen Primärschlüssel angibst. Der SELECT sucht alle Materialien des Lieferanten und prüft bei jedem davon, ob es irgendein Werk gibt, in dem es das Dispositionsmerkmal VI hat. Du bekommst also Anzahl Materialien des Lieferanten x Anzahl Werke Suchergebnisse, die dann sequentiell nach den übrigen Kriterien (Regellieferant, kein Löschkennzeichen) abgeprüft werden.

Du könntest die Performance sicherlich erhöhen, indem Du auch das Werk (MARC-WERKS) angibst, sofern Du das eingrenzen kannst. Ansonsten wäre auch ewx' Ansatz möglich, auf der MARC einen neuen Index MATNR/DISMM zu definieren. Auch auf der EINA könntest Du einen Index LIFNR/RELIF anlegen. Allerdings sollte man mit Indizes sparsam umgehen und möglichst keine Datenbankindizes anlegen, die man nur in einem einzigen Programm braucht.

Ich bezweifle aber, dass dieser SELECT einzeln ein nennenswertes Performanceproblem aufwirft. Vermutlich hast Du da eine LOOP-Schleife, in der Du ihn häufiger ausführst. Hast Du das Problem nur in dem einen Report, dann kannst Du Dir auch dort eine lokale Pufferung anlegen. Beispielsweise könntest Du sagen:

Code: Alles auswählen.

DATA: BEGIN OF WA,
        PARNR LIKE EINA-LIFNR,
        VIX LIKE EINA-RELIF,
      END OF WA.

DATA MARC_PUFFER TYPE SORTED TABLE OF MATNR WITH UNIQUE KEY TABLE_LINE.

* einmal zu Programmbeginn Puffer füllen mit:
SELECT DISTINCT MATNR INTO TABLE MARC_PUFFER FROM MARC
 WHERE DISMM = 'VI'.

* Dein optimierter, öfters im Programm verwendeter SELECT:
SELECT RELIF INTO WA-VIX FROM EINA UP TO 1 ROWS
  FOR ALL ENTRIES IN MARC_PUFFER WHERE LIFNR = WA-PARNR
                              AND MATNR = MARC_PUFFER-TABLE_LINE
                              AND RELIF = 'X'
                              AND LOEKZ = SPACE.
ENDSELECT.
In dem Fall brauchst Du tatsächlich den UP TO 1 ROWS, weil FOR ALL ENTRIES IN mit SELECT SINGLE nicht funktioniert.

Alternativ könntest Du auch andersrum herangehen, alle Materialien des Lieferanten puffern und dann den SELECT auf der MARC machen. Was besser ist, hängt von den Umständen in Deinem Programm ab. Aber so hast Du nur einen dicken SELECT zu Programmbeginn.

Wenn Du den SELECT richtig viel im Programm brauchst (und Dein Performanceproblem könnte ein Hinweis darauf sein), dann kannst Du sogar beides puffern und dann nur noch im Hauptspeicher arbeiten. Das ist dann richtig rasant, HANA-style. :-D

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


Seite 1 von 1

Vergleichbare Themen

14
Antw.
2481
Views
Performance Problem
von ChrissixD » 26.09.2017 09:13 • Verfasst in ABAP® für Anfänger
70
Antw.
16057
Views
Performance-Problem
von cuncon » 27.02.2018 07:41 • Verfasst in ABAP® für Anfänger
18
Antw.
6515
Views
Performance-Problem bei SELECT
von Charadin » 22.10.2007 08:10 • Verfasst in ABAP® Core
8
Antw.
4214
Views
Speicher & Performance Problem bei XML einlesen
von Zubasa » 15.06.2011 13:48 • Verfasst in ABAP® für Anfänger
1
Antw.
151
Views
Laden Archivierter Daten - Performance Problem
von tom125 » 03.02.2021 10:44 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 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 3 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 3 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