Performance-Probleme

Performance-Probleme

DeathGuardian hat geschrieben:Wieso ist es auf dem Entwicklungssystem schneller als auf dem Testsystem?
Ich weis ja nicht, wie es bei euch aussieht, aber bei uns hat das E-System eher weniger bis gar keine Daten und das Testsystem ist verhältnismässig Produktivsystem nah.
Sprich E hat weniger Daten deshalb auch schneller, weil weniger zu selectieren.

Das ist wohl wahr, aber das das ganze gleich derart ausartet?

Ich dachte JOINs sind immer schneller, als wenn man jede DB-Tabelle einzeln selektiert?!
In der Regel ja, aber die Regel trifft nicht immer zu.

Du machst aktuell einen JOIN von LIPS der auf VBAK und VBAP gleichzeitig geht.
Mach daraus mal ein JOIN der von LIPS auf VBAP und dann von VBAP auf VBAK geht.
Das wird glaub ein wenig was raushollen und auch dafür sorgen, das das Ergbnis genauer wird.

Also werde ich den Select soweit ändern, dass ich nicht 2mal die Lips hernehme.
Dann sieht der FROM Teil so aus:

Code: Alles auswählen.

    FROM ( ( ( likp AS b INNER JOIN lips AS e
           ON b~vbeln = e~vbeln )
           INNER JOIN vbap AS d
             ON  d~vbeln = e~vgbel
             AND d~posnr = e~vgpos )
             INNER JOIN vbak AS a
               ON a~vbeln = d~vbeln )
               INNER JOIN vbkd AS f
                 ON  f~vbeln = d~vbeln
                 AND f~posnr = d~posnr

Eventuell würden auch ein paar Index helfen.

Krueger hat geschrieben:Mein Vorschlage.../...Ich würde es mal so versuchen:

1.) INTO CORRESPONDING FIELDS OF TABLE gt_all
in der internen Tabelle GT_ALL genau die Felder aufnehmen, die ich in dem Join auch nur brauche, damit diese "INTO CORRESPONDING" wegfällt.

Lesen der KOPFtabellen in interne Tabellen und anschliessend ein Select auf die POSITIONSTabellen mit "FOR ALL ENTRIES".

Meine Erfahrungen mit JOIN's: Wenn die Joins zu gross werden, geht die Performance in die Knie und eine Select... Endselect ist performanter.
Das händeln der riesigen internen Tabellen wirkt sich zu sehr negativ aus.

Wie bereits erwähnt, evtl. mit bedacht INDEXe in der SE11 auf die DB anlegen.



Edit: "VERSUCH MACHT KLUCH!!!"

JHM hat geschrieben:...
MOVE-CORRESPONDING ist immer unperformant und gehört verboten, ist nur etwas für faule Programmierer.
...

• Diese Anweisung(en) sind zumindest dann notwendig, wenn man z.B. dynamische SELECTS baut, wo die Feldliste wegen dynamischer Ziele nicht angegeben werden kann.
• Ein anderer Fall besteht dort, wo man am SAP-Standard oder in Branchenlösungen arbeitet, wenn man Strukturen verwendet, die typischer Weise durch kundeneigene Felder erweitert wurden. Wenn man da alle Feldzuweisungen explizit programmiert, wie das m.W. in der Bestandsführung der Fall ist, haben die Kunden viel Spaß mit dem Modifizieren.
• Erweiterungen in Kundenprogrammen, wo man wegen der expliziten Verwendung von Zuweisungen, alle betroffenen Programme anpassen muss, sorgen auch für viel Freude.
• etc.

ereglam hat geschrieben: es hängt immer von der Art der Anwendung ab, welche Sprachkonstrukte sinnvoll sind.
Etwas pauschal zu verdammen, weil man die gesamte Bandbreite der Anwendungen nicht kennt, halte ich für unangebracht.