Select performanter machen

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

Select performanter machen

Beitrag von nikibert (ForumUser / 78 / 4 / 0 ) »
Moin Moin,
heute ist bei uns "Zeiteinspartag".

Hat jemand eine Idee wie man folgenden Select performanter machen kann?

select a~matnr
a~werks
a~lgort
a~bwart
b~blart
a~menge
a~meins
a~dmbtr
b~budat
from mkpf as b
inner join mseg as a on
b~mblnr = a~mblnr and
b~mjahr = a~mjahr
into table gt_bwdat
where b~budat in so_budat
and a~werks in so_werks
and a~matnr in so_matnr.

Danke & Gruß
nikibert

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


Re: Select performanter machen

Beitrag von ralf.wenzel (Top Expert / 3921 / 200 / 280 ) »
nikibert hat geschrieben:Hat jemand eine Idee wie man folgenden Select performanter machen kann?
Der sieht schon richtig gut aus - ich mag halt diese Aliase (... as b) nicht, aber das ist ne Stilfrage. Viel Potential ist da nicht - ein Join "into table", where-Bedingung in der Reihenfolge der Felder in der Join, nur die Spalten gezogen die man auch braucht.

Ich hätte den SELECT genau so geschrieben. Wenn du wirklich Stress mit diesem SELECT hast, sehe ich eigentlich nur drei Möglichkeiten:

* Tabellenpuffer verwenden (dann scheidet der JOIN allerdings aus)
* View auf der Datenbank statt im Coding
* Schlüsselfelder vorselektieren und mit diesen scharf auf die Einträge schießen (ich weiß aber nicht ob das Laufzeit bringt oder kostet, müsste man testen)

Indizes verbiegen schließe ich mal aus, wenn ich mir die WHERE-Bedingung so ansehe.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Beitrag von nikibert (ForumUser / 78 / 4 / 0 ) »
Moin,

ich habe es befürchtet. Leider läuft das Ding einfach zu lange.
Kann es sein das einzelne Tabellen probleme haben können? Habe heute morgen zu hören bekommen das alle Abfragen auf die MSEG ein wenig Probleme haben.

Unser Mann von der Basis beschäftigt sich grad mit dem Problem... Woran es liegen könnte, keine Ahnung!?!

Gruß nikibert

Beitrag von wreichelt (Top Expert / 1046 / 30 / 192 ) »
Hallo,
ja klar , richtig erkannt, Zugriffe auf die MSEG sind sehr aufwendig.
Es gibt schon einige Performance-Tips im OSS zum Beispiel 191492.
Evtl ist da etwas dabei was weiterhilft.
Gruß Wolfgang

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
Ich hatte auch schon mal ein System, in dem die Joins total langsam waren, da die DB trotz vollem Schlüssel einen Fulltablescan gemacht hat...
Ich würde probieren, den Join in zwei Selects aufzulösen.
1. Select MPKF; auf BUDAT sitzt auf "meinem" aktuellen System ein Index.
2. Select MSEG for all entries.
Auch wenn's eigentlich nicht schneller sein sollte, manchmal gibt's Überraschungen... ;-)
Du könntest übrigens das Belegjahr noch mitgeben.
Manchmal wird ein Select sogar einfach nur dadurch schneller, dass man ein Feld mittels WHERE-Bedingung einschränkt, obwohl man mit der Bedingung eigentlich alle Daten einschliesst. Soll heissen WHERE MJAR BETWEEN 1800 AND 3000 oder WHERE vgart BETWEEN AA AND ZZ...

Aber da der Zusatz INTO CORRESPONDING-FIELDS anscheinend auch nicht mehr so ein Zeitfresser ist, sind meine Infos evtl. auch schon veraltet... :roll: Einfach ausprobieren.

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
Das ist ohne genaue Kenntniss des Systems und der Parameter für den
Aufruf schwierig zu beantworten.

Poste mal bitte den Ausführungsplan des Optimizers zu diesem Statement
und die Inhalte der budat, werks und matnr Select-Options.
Eine Abschätzung der Treffer je Key-Feld wäre sehr hilfreich.

Gruss
Daniel

Beitrag von nikibert (ForumUser / 78 / 4 / 0 ) »
Moin,
hab da was gefunden was mich sehr verwundert hat.
Konnt die Laufzeit wirklich um ca 1,5 Std. verkürzen von 1,5 Std auf 14 Sec!
Unglaublich aber wahr!

Die folgende Einschränkung in der where-Bedingung habe ich rausgenommen.
"and a~matnr in so_matnr."

Anschliessend schmeiss ich einfach die nicht gewünschten Materialien einfach aus der internen Tabelle. Läuft einwandfrei und bekomme das gleiche Ergebnis.

Gruß nikibert

Beitrag von Martin8703 (ForumUser / 12 / 0 / 0 ) »
Das muss keine Hexerei sein. Evtl. nutzt der DB-Optimizer mit Wegfall der Matnr nun einfach einen Sekundärindex (und macht somit keinen Full-Table-Scan).

Von der Syntax her ist das Select-Statement in Ordnung, wie Daniel schon sagte gibt es da noch andere Dinge, die man optimieren kann/sollte, wenn es auf Performance ankommt.

Indizes lassen sich über die Tabellenanzeige in der SE11 finden (unter Springen -> Indizes zu finden). Nützlich auch der SQL-Trace (ST05).

Interessant wäre sicherlich, warum er jetzt so viel schneller ist. Evtl. eine gute Übung für die Testwerkzeuge ;)

Seite 1 von 1

Vergleichbare Themen

1
Antw.
611
Views
Performanter Select
von gs3rr4 » 16.07.2014 12:19 • Verfasst in ABAP® für Anfänger
5
Antw.
4403
Views
Was ist performanter? Select auf DB oder Read auf itab?
von airwaver » 06.06.2007 13:05 • Verfasst in ABAP® Core
2
Antw.
2550
Views
Select * und Select von einzelnen Werten zugleich
von StefanJue » 04.10.2006 18:10 • Verfasst in ABAP® für Anfänger
4
Antw.
9327
Views
Performance: SELECT UP TO 1 ROWS vs. SELECT SINGLE
von roman1983 » 04.09.2008 14:29 • Verfasst in ABAP® für Anfänger
8
Antw.
3040
Views
SELECT SINGLE oder SELECT UP TO 1 ROWS?
von nickname8 » 12.04.2021 10:38 • Verfasst in ABAP® für Anfänger

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.

Unbeantwortete Forenbeiträge

Daten an Tabelle binden
Gestern von Bright4.5 1 / 499
aRFC im OO-Kontext
vor 4 Wochen von ralf.wenzel 1 / 2139
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 8735