Laufzeit von Programmen in 3-System-Landschaft

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

Laufzeit von Programmen in 3-System-Landschaft

Beitrag von btml06 (ForumUser / 12 / 0 / 0 ) »
Hallo miteinander,

wir haben ein Laufzeitproblem mit einem Report, ist wirklich ein großes Teil.

Da der Report so ein Uralt-Teil ist, habe ich ihn im Coding beschleunigt. Lief im Entwicklungssystem nur noch halb so lang - war echt stolz auf mich ;-)

Transport ins Quali brachte die große Ernüchterung! Es war kein, überhaupt kein Effekt zu erkennen!!! Dasselbe Sch...Spiel im Produktivsystem! (Die Laufzeiten haben sich zum Glück nicht noch verschlechtert.)

Ich habe für Job-Log neue Meldungen eingebaut, es wird wirklich die neueste Version gezogen.

Hat jemand schon mal so einen Effekt gehabt?!?!

Hoffe auf Anregungen. Danke
btml06

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


Beitrag von DeathGuardian (Expert / 759 / 0 / 3 ) »
Naja, in der Regel ist bei sowas die Datenbank schuld.
Eventuell mal die Tabellen welche im Zugriff sind Archivieren.
Oder mal nach Index schauen.
Meist sind das die Hauptprobleme bei den Laufzeiten.

Beitrag von btml06 (ForumUser / 12 / 0 / 0 ) »
Archivierung - keine Chance (nicht gewollt).

Logisch läuft der Report im Prod länger als im Quali, und im Quali länger als im Entwicklung. Einfach wegen der Menge der Daten. Aber eine Beschleunigung im Entwicklungssystem lässt doch eine Beschleunigung in den anderen Systemen erwarten, wenn auch auf anderem Niveau.

Berücksichtigung der vorhandenen Indizes war ja gerade Teil der Beschleunigung. Diese sind identisch in den drei Systemen.

Die drei Datenbanken liegen auf einem gemeinsamen Block eines sogenannten Filers. Es gab zB den Effekt, dass die Bandsicherung auf einem der drei Systeme auch die anderen beiden Systeme verlangsamt hat, weil der Engpass beim Filer war. Normalerweise kommen sich die drei DB aber nicht in die Quere.

Sonst noch Ideen? Wir sind nämlich inzwischen diesbezüglich ziemlich ratlos.

Gruß
btml06

Beitrag von TWP (Specialist / 445 / 0 / 1 ) »
Gibt sicherlich ne ganze menge an diengen, die man tun kann,

- interne Tabelle klein halten (vo der breite her)
- felder beim select begrenzen (nur die, die man braucht)
- into table , statt into corresponding fields of table
- select - endselect vermeiden
- ggf. mit sortierten Tabellen arbeiten
- nachlesen von Daten für die Tabelle mit assignigng um Modify auszuschalten
* nachlesen der benötigten Daten ggf. über Gruppenwechsel um
nicht für jeden Satz den gleichen Datensatz nachzulesen

- usw...

Vielleicht steht da nu was, was du noch nicht berücksichtigt hast. Wenn nicht kannst du ja mal ein Stück Problemcoding posten.

MfG

Thomas

Beitrag von edwin (Specialist / 306 / 11 / 68 ) »
Hallo btml06,

1. schaue Dir mal die Statistiken an, sind diese auf der Q/P aktuell ?
2. Lasse einen DB-Trace mitlaufen, wird der Index auch benutzt ?

Gruss Edwin

Beitrag von TWP (Specialist / 445 / 0 / 1 ) »
Wenn wir einmal beim prüfen sind.

Habt ihr das Programm in Q/P mal mit der SE30 laufen lassen? Aus der Laufzeitanalyse ist gut sichtbar, wo die Zeit verloren geht.

Thomas

Beitrag von btml06 (ForumUser / 12 / 0 / 0 ) »
Hallo alle miteinander,

hoffe Ostern gut verlebt zu haben. Wir waren rodeln ;-)


At TWP
Die Code-Anpassung hat im Wesentlichen deine Tipps berücksichtigt. Es hat sogar noch mal unser "Ober-Guru" drübergeschaut.

At edwin.
Trace sagt, Index wird gezogen.



Laut Job-Log ist das Hauptproblem die Selektion der VBAK VBAP.



Ich habe das Coding von geschachtelten SELECTS auf JOIN umgestellt. Es heißt, bei sehr großen Tabellen sei der JOIN problematisch. Aber, wie im ersten Eintrag gesagt: iim E-System rennt der Report, im Q und P dauerts mehr als doppelt so lange. Sooo groß finde ich die Unterschiede der Tabellen aber nicht:

Entwicklung (wurde seit Umstieg von 2 auf 3 Systeme nicht bereinigt)
VBAK knapp 900.000 Einträge
VBAP knapp 7.000.000 Einträge

Quali
VBAK 1.000.000
VBAP 7.900.000

Produktiv
VBAP 1.100.000
VBAP 8.300.000


Hier etwas altes Coding:

Code: Alles auswählen.

form SELECT_KDAUF_ALT .

* SELECT * FROM VBAK
  SELECT vbeln auart
             INTO (xvbak-vbeln, vbak-auart)
*            INTO CORRESPONDING FIELDS OF XVBAK FROM VBAK
           FROM vbak
           WHERE vkorg EQ p_vkorg
             AND vtweg EQ p_vtweg
             AND auart IN s_aufart
             AND vbeln IN s_vbeln
             AND ( vbtyp EQ 'C' OR vbtyp EQ 'I' ) .
* Beginn AS20030413
    CHECK vbak-auart NE 'ZBK'.
    CHECK vbak-auart NE 'ZPT'.
* Ende AS20030413
* Beginn BZ25042006
    CHECK vbak-auart NE 'ZDB'.
* Ende BZ25042006
* SELECT * FROM VBAP
    SELECT vbeln posnr kwmeng
               INTO (xvbap-vbeln, xvbap-posnr, xvbap-kwmeng)
*              INTO CORRESPONDING FIELDS OF XVBAP FROM VBAP
               FROM vbap
                 WHERE vbeln EQ xvbak-vbeln
                   AND fkrel NE space  " fakturarelevant: JA
                   AND abgru EQ space  " kein absagegrund
                   AND kwmeng NE 0.

      CLEAR ex.
      MOVE xvbak-vbeln  TO ex-vbeln.
      MOVE xvbap-posnr  TO ex-posnr.
      MOVE xvbap-kwmeng TO ex-aemenge.
*     EXTRACT POSTEN.
      APPEND ex.

    ENDSELECT.
  ENDSELECT.

endform.                    " SELECT_KDAUF_ALT

und hier neues Coding
(Die itab ex ist aus historischen Gründen vorhanden, wird später weiterverwendet und muss deshalb gefüllt werden.)

Code: Alles auswählen.

form SELECT_KDAUF_NEU .

  SELECT K~VBELN
         P~POSNR
         P~KWMENG
         P~FKREL
         K~AUART

    FROM VBAK AS K

    INNER JOIN VBAP AS P
    ON K~VBELN = P~VBELN

    INTO TABLE IT_KDAUF

    WHERE K~VBELN IN S_VBELN
      AND P~POSNR IN R_POSNR
      AND K~VKORG EQ P_VKORG
      AND K~VTWEG EQ P_VTWEG
      AND K~AUART IN S_AUFART
      AND ( K~VBTYP EQ 'C' OR K~VBTYP EQ 'I' )
      AND P~ABGRU EQ SPACE.

  DELETE IT_KDAUF WHERE AUART  EQ 'ZBK'.
  DELETE IT_KDAUF WHERE AUART  EQ 'ZPT'.
  DELETE IT_KDAUF WHERE AUART  EQ 'ZDB'.
  DELETE IT_KDAUF WHERE KWMENG EQ 0.
  DELETE IT_KDAUF WHERE FKREL  EQ SPACE.

* ex füllen
  LOOP AT IT_KDAUF ASSIGNING <WA_KDAUF>.

    CLEAR EX.
    EX-VBELN   = <WA_KDAUF>-VBELN.
    EX-POSNR   = <WA_KDAUF>-POSNR.
    EX-AEMENGE = <WA_KDAUF>-KWMENG.

    APPEND EX.

  ENDLOOP.                      " it_kdauf

  FREE IT_KDAUF.

endform.                    " SELECT_KDAUF_NEU

Ich habe eigentlich den Verdacht, dass es nicht am Programm und am Coding liegt, da die Tabellen nicht so unterschiedlich sind. Ich vermute eher ein Basis-Problem, aber die Basis-Leute wissen auch nichts mehr.

Gruß
btml06

Beitrag von JHM (Top Expert / 1213 / 2 / 202 ) »
btml06 hat geschrieben: (Die itab ex ist aus historischen Gründen vorhanden, wird später weiterverwendet und muss deshalb gefüllt werden.)
So wie beide Codings aussehen, wird in der FORM nur die Tabelle EX gefüllt.
Wieso füllst du EX dann nicht direkt beim Select?

Die DELETEs auf die Itab kannst du dir auch noch sparen, in dem du diese mit in die Where-Bedingung einbaust. So werden weniger Daten gelesen und somit auch übers Netz geschickt.
Gruß Hendrik

Beitrag von MarkusW (Specialist / 406 / 5 / 0 ) »
Hallo,

zu deinem Problem hab ich keine Lösung, nur ein Erfahrungsbericht.

Hatte selbst mal ein Programm bei einem Kunden umschreiben müssen, da es zu langsam war (Zusätzlich sollten noch weitere Tabellen abgefragt werden)

Ich also voller Stolz alles mit Join´s gemacht und alle waren total begeistert von der Geschwindigkeit auf dem Entwicklersystem.
Dann Transport ins Q und dann die staunenden Blicke :shock: Laufzeit war die Hölle :twisted:

Oki gegrübelt, (auch hier im Forum die Leute befragt...kann dir leider den Thread nicht sagen, find ihn nicht)

Mit Join´s war es nicht zu machen...musste wieder auf geschachtelte Select...Endselect Anweisungen umstellen. Da dann eben soweit wie möglich alles beachtet, was auch TWP genannt hatte, drauf geachtet das nur Keyfelder in den SelectAnweisungen waren und dann wieder ins Q. Unglaublich :o aber das ging x-mal schneller, als nen Join.

Evtl. bei dir das gleiche Problem?!
Das System selber muss dafür 'eingerichtet' sein, ob nun Joins bevorzugt verarbeitet werden oder normale Selects... (so zumindest die Aussage damals von der Basis...da ich nix am Hut habe, mit Basis wissen, hab ich dem mal geglaubt.)

Gruß
Markus

Beitrag von btml06 (ForumUser / 12 / 0 / 0 ) »
Hallo JHM,

die ex wird auch noch aus der VBRK und VBRP befüllt und hat noch zig weitere Felder. Die Struktur der ex werde ich natürlich nicht ändern, da ich nicht weiß, was genau im weiteren Coding noch passiert. Bei "Select into table" brauche ich die richtige Reihenfolge der Spalten.

Zuerst hatte ich alle Selektionen in der WHERE-Klausel. Unser "Programmier-Guru" meinte, negative Selektionen in der Where-Klausel kosten Zeit, da sequentielle Selektion. Besser sei Ablöschen danach.

Gruß
btml06

Beitrag von TWP (Specialist / 445 / 0 / 1 ) »
Trenn dein Join wieder auf:

1) lesen VBAK mit deinen Selektionen in lt_vbak
- da VBAK keinen INDEX hat der dir hilft, kannst du hier sicherlich auch
die Anforderungen auf dem Delete schon benutzen

2) Loop übder lt_vbak und dann immer ein Select auf die VBAP mit apending into table ...

Damit hast du für deinen Loop der die EX - befüllt nur die Daten die du benötigst.

Vielleicht hilft es dann doch noch etwas Laufzeit rauszuholen.

Sonst das Programm mal mit der SE30 prüfen und schauen über den Absprung ins Coding, ob diese Select's wirklich das Problem sind.


MfG

Thomas

Beitrag von index (ForumUser / 17 / 0 / 0 ) »
Hi,

hasst du schon mal überprüft, wieviele Datensätze du holst?
wenn aufgrund der bescheidenen Datenqualität auf dem Entwicklungssystem nur ein bruchteil der Daten geholt wird wie auf dem Q oder P verlierst du natürlich den Vorteil der schnelleren Selektion.

Die muss übrigens schnell sein, da du voll qualifiziert zugreifst, wenn in deiner Belegnr-Range was drin steht. Wenn die leer ist, liest du natürlich sequentiell alles, da er dann wegen der where-Felder den Primärindex nimmt und 7Mio Datensätze brauchen Zeit.
Und schmeisst dann evtl. 6Mio über die Deletes wieder raus.

Falls du also mit leerer Belegnr-Range liest, solltest du die Where-Bedingung auf einen anderen Index umstellen.

Die Deletes solltest du vermeiden, da die auf eine unsortierte Tabelle auch lang laufen, du kannst dir die auart-Range ja vorher mit den Werten füllen die du brauchst und kwmeng mit > 0 und fkrel ebenfalls mit vorher gefüllter Range abfragen.

Ist halt immer viel gucken und tun und machen ;-)

Seite 1 von 1

Vergleichbare Themen

4
Antw.
2903
Views
Transporte nach Systemkopie (3-System Landschaft)
von SAP_ENTWICKLER » 18.09.2014 14:22 • Verfasst in ABAP® Core
1
Antw.
4533
Views
7
Antw.
6377
Views
Transport von SAP-Programmen.
von Anfänger » 28.10.2010 12:38 • Verfasst in ABAP® für Anfänger
0
Antw.
2049
Views
Aufrufhierarchie von Programmen
von a-dead-trousers » 15.10.2012 10:59 • Verfasst in ABAP® Core
1
Antw.
1374
Views
Tabellendefinition aus Programmen erzeugen
von c0lt.seavers » 12.02.2007 15:30 • Verfasst in Basis

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.