Dauer Selektion

Dauer Selektion

Morgen,

mal eine Frage an die Leute von der Basis:
Kann es sein, dass eine Selektion mit einem Report auf die Tabelle BKPF und BSEG, wo ca 100.000 DS selektiert werden, mehrere Stunden dauert?

Oder ist da was falsch konfiguriert?

Mfg

Re: Dauer Selektion

Anonymous hat geschrieben:Morgen,

mal eine Frage an die Leute von der Basis:
Kann es sein, dass eine Selektion mit einem Report auf die Tabelle BKPF und BSEG, wo ca 100.000 DS selektiert werden, mehrere Stunden dauert?

Oder ist da was falsch konfiguriert?

Mfg

Falsch konfiguriert wohl nicht, aber deine Datenselektion gilt es zu optimieren. Poste sie doch mal, dann werden wir uns darauf stürzen *g


Ralf

Es hat sicher niemand was dagegen wenn du zumindest deinen Vornamen nennst, jemand anonymen anzusprechen ist immer etwas "holzig" *g

Anonymous hat geschrieben:na dann mal viel spass damit

Code: Alles auswählen.

* Selektion BKPF & BSEG
  SELECT *  FROM bkpf CLIENT SPECIFIED
      INTO CORRESPONDING FIELDS OF wa_bkpf
      WHERE mandt EQ sy-mandt
      AND bukrs EQ sbukrs
      AND gjahr EQ sgjahr
      AND monat EQ smonat
      AND budat IN sbudat.
    APPEND wa_bkpf TO it_bkpf.

    SELECT * FROM bseg CLIENT SPECIFIED
      INTO CORRESPONDING FIELDS OF wa_bseg
        WHERE mandt = sy-mandt
        AND bukrs EQ sbukrs
        AND gjahr EQ sgjahr
        AND belnr EQ wa_bkpf-belnr.
      APPEND wa_bseg TO it_bseg.
      CLEAR wa_bseg.

    ENDSELECT.
    CLEAR wa_bkpf.
  ENDSELECT.

Also, auf den ersten Blick und ohne gerade viel Zeit zu haben, würde ich sofort die Verschachtelung der zwei selects entfernen.

Meine Standardselektionsmethode ist ein "into table..." bzw. "appending table....", das ist in aller Regel erheblich performanter als das einzelne Wegschreiben per append.

Dann kannst du auch sehen, welcher der beiden selects sovijel Zeit braucht, ich tippe massiv auf BSEG, BKPF ist in aller Regel erheblich performanter anzuzapfen.

Brauchst du unbedingt ALLE Felder von BSEG und BKPF? Das kann ich mir kaum vorstellen. Mach doch mal ne Feldliste der Felder, die du WIRKLICH brauchst und du wirst staunen, wie schnell gerade die BSEG-Selektion wird.

Das mal als zwei erste Tips, schreib bitte mal obs erfolgreich war und die Selektion schnell genug ist. Wenn nicht, müssen wir weiter optimieren.


Ralf *der inzwischen selbstst. Datenschutzbeauftragter ist und nur noch Altkunden mit SAP betreut

Noch zwei Fragen:

Hat es einen besonderen Grund, warum das Schlüsselfeld BELNR nicht in der BKPF-Selektion vorkommt?

Deine Variablenbezeichnungen sind etwas verwirrrend, bei "sbukrs" würde ich vom Namen her auf eine select-option tippen, dann ist EQ aber nicht wirklich logisch. sbukrs ist ein Parameter?

Hallo,

die Selektion des Belegkopf benötigt soviel Zeit, das die Bedingung keinem Indizes entspricht. Außerdem ist die Schachtelung nicht zu empfehlen.

Geschäftsjahr und Monat habe ich aus der BKPF-Bedingung rausgeschmissen. Wenn Du das unbedingt benötigst solltest Du Dir aus den beiden Angaben ein Datumsrange zusammenbasteln und dann damit das Buchungsdatum selektieren.

Ich habe die Selektion mal optimiert. Hier das Beispiel:
Sorry, alles auf die Schnelle. Habe leider keine Zeit für mehr Ausführungen.
Gruß,
Dirk

Florian hat geschrieben:die ganzen variablen sbukrs etc sind schon richtig, eingetragen, habs halt nur einfach so benannt egal ob es select options oder paramenter sind.

Das ist grundsätzlich suboptimal, aus einem Variablennamen sollten die wichtigsten Eigenschaften der Variable hervorgehen. Ist es eine Tabelle? Oder eine Range? oder ein unstrukturiertes Feld? Das sollte man schon am Namen ablesen können -- ansonsten kannst du die Variablen auch "Peter" und "Susi" nennen.

Keine Bevormundung, nur ein Tip von jemandem, der sich über nichtssagende Variablennamen von anderen schon massiv geärgert hat, wenn er deren Programme weiterentwickeln musste.

Florian hat geschrieben:funktioniert "select into table itab" auch wenn ich denn nur ein paar felder selektiere, also z.B. "selekt mandt, belnr, monat, ... from bkpf into table itab" ?

Das funktioniert immer, die Feldliste muss halt genauso aussehen wie die itab, das ist wichtig dabei.

Ich verwende gern "for all entries" -- auch wenn das nicht ganz unumstritten ist, und man aufpassen muss dass die referenzierte Tabelle NICHT leer ist, sonst wird nämlich alles selektiert *g


Ralf

ereglam hat geschrieben: @Haubi
Florian hat in einem seiner Postings angegeben, dass er die beiden Tabellen noch für spätere Schritte benötigt. Daher ist die Verwendung von PACKAGE-SIZE nur dann zu empfehlen, wenn die nachfolgenden Schritte sich in der Schleife abspielen würden.

Wäre ja auch kein Problem. Den SELECT auf die BKPF in eine "temporäre" ITab mit allen Feldern, die benötigt werden. Vor dem ENDSELECT werden dann die Zeilen der temporären ITab mittels "APPEND LINES OF" an die "Nutz-ITab" angehängt. Auf jeden Fall läuft der SELECT auf die BSEG wesentlich schneller, da massenhaft Sätze verarbeitet werden.

Gruss,
Haubi

Hi,
normale Select-Schleifen sind kein Problem, nur geschachtelte sind es.

In einer Select-Schleife wird in der Datenbank auch nicht Satz für Satz gelesen, sondern immer ein Kontrollblock gefüllt, auf den Appl-Server übertragen und dann Satz für Satz dem Programm bereitgestellt.

Der Einsatz von Select-Schleifen ist eigentlich immer dann gegeben, wenn die selektierte Datenmenge potenziell sehr gross sein kann, so dass ich sie nicht einfach in eine interne Tabelle schieben kann. Dabei kann aber auch Package Size wie bereits erwähnt einen Vorteil bieten.

In der Online-Doku sind die wichtigsten Punkte, die man hinsichtlich Performance beachten sollte, sehr gut beschrieben. Es lohnt sich da mal 'reinzuschauen.

Wichtig finde ich auch den Hinweis auf die Feldauswahl, aus Bequemlichkeit (?) wird leider häufig ein SELECT * verwendet, was sehr viele Auswirkungen hat (weniger Sätze pro Kontrollblock, höherer Speicherbedarf, längere Laufzeit, es muss immer auf die Haupttabelle zugegriffen werden, obwohl vielleicht alle benötigten Daten schon in einem Index sind, etc.).

Gruß, Olaf

black_adept hat geschrieben:

ralf.wenzel hat geschrieben:Beispiel:
Innerhalb der SELECT-Schleife wird eine asynchrone Task gestartet ( Um den COMMIT innerhalb des SELCECt zu vermeiden ), die Daten in die Tabelle einfügt, über die man grade den Select macht.

Der Fall ist immer problematisch.
Das Starten der asynchronen Task bewirkt im aufrufenden Prozess ein DB-commit.
Daher wäre schon mal ein OPEN CURSOR WITH HOLD ..., FETCH ... nötig.

Dann braucht man aber auch keine asynchrone Task mehr, nur um ein DB-commit abzusetzen.
Jedoch hilft der DB-Commit nicht dagegen, dass die Rollback Area volläuft, wenn Du die Tabelle, aus der gelesen wird, änderst.