INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Bright4.5 » 07.12.2018, 13:22

Hey,

ich bin gerade dabei ein Programm performanter zu gestalten, da es zu langsam läuft.

Ich hab hier bei einem Inner join (Select) ein Into Corresponding Fields of table eingebaut. Ich hab glaub ich damals gelernt Into Table sei deutlich performanter (schneller). Irgendwelche Meinungen dazu ??

Into Table sollte deutlich schneller sein, oder?
Bright4.5
ForumUser
 
Beiträge: 95
Registriert: 17.08.2018, 18:23
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Tommy Nightmare » 07.12.2018, 13:40

Beim "INTO CORRESPONDING" gibt es noch den zusätzlichen Schritt, die passenden Zielfelder zu suchen, ohne das "CORRESPONDING" wird das nicht geprüft.
Wenn die angegebene Tabelle hinter "INTO" dann den falschen Typ hast, hast du als Ergebnis natürlich nichts sinnvolles.

Aber lass es uns mal testen:
Code: Alles auswählen
DATA t_t002 TYPE TABLE OF t002.

GET RUN TIME FIELD DATA(t0).

SELECT *
  FROM t002
  INTO CORRESPONDING FIELDS OF TABLE t_t002.

GET RUN TIME FIELD DATA(t1).

CLEAR t_t002.

GET RUN TIME FIELD DATA(t2).

SELECT spras laspez lahq laiso
  FROM t002
  INTO TABLE t_t002.

GET RUN TIME FIELD DATA(t3).

DATA(r0) = t1 - t0.
DATA(r1) = t3 - t1.

WRITE:
  r0, /, r1.
 

In meinem Beispiel lief der Select mit "INTO CORRESPONDING" immer ca. 2,5 mal länger.

Ich würde also von immer empfehlen, die zu selektierenden Felder in die Select Liste zu schreiben und das "CORRESPONDING" wegzulassen.
In den meisten Fällen weiß man ja vorher schon, welche Felder man braucht.

LG Tommy
Tommy Nightmare
ForumUser
 
Beiträge: 27
Registriert: 08.09.2017, 11:38
Dank erhalten: 1 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon nickname8 » 07.12.2018, 13:46

Es ist in der Tat ein wenig langsamer, weil die richtigen Daten gemappt werden müssen. Aber dies ist nicht die erste Stellschraube, an der gedreht werden sollte wenn es um Performance geht.
Eher

Datenbankzugriffe optimieren
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen

Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen

nur so paar Anhaltspunkte :-)

Für diese Nachricht hat nickname8 einen Dank bekommen :
Legxis
nickname8
ForumUser
 
Beiträge: 78
Registriert: 18.07.2015, 08:22
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon nickname8 » 07.12.2018, 14:00

Tommy Nightmare hat geschrieben:In meinem Beispiel lief der Select mit "INTO CORRESPONDING" immer ca. 2,5 mal länger.

Ich würde also von immer empfehlen, die zu selektierenden Felder in die Select Liste zu schreiben und das "CORRESPONDING" wegzulassen.
In den meisten Fällen weiß man ja vorher schon, welche Felder man braucht.

LG Tommy


Bei mir ist es grade so, dass ohne CORRESPONDING viel länger dauert. Ich war aber auch so frei dein Testprogramm dahingehend zu ändern, das erst der Select ohne CORRESPONDING aufgerufen wird und dann erst der mit.

Ich denke du kommst selber drauf, warum das so ist :)
nickname8
ForumUser
 
Beiträge: 78
Registriert: 18.07.2015, 08:22
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Tommy Nightmare » 07.12.2018, 14:47

Wenn ich immer einen Select auskommentiere, ist der ohne "CORRESPONDING" trotzdem eher schneller.
Trotzdem ist der erste Select von beiden immer langsamer, anscheinend wird das irgendwie gepuffert...
Tommy Nightmare
ForumUser
 
Beiträge: 27
Registriert: 08.09.2017, 11:38
Dank erhalten: 1 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon nickname8 » 07.12.2018, 15:22

Tommy Nightmare hat geschrieben:anscheinend wird das irgendwie gepuffert...


Wird es.

https://ibb.co/HGR3XmF
nickname8
ForumUser
 
Beiträge: 78
Registriert: 18.07.2015, 08:22
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Bright4.5 » 10.12.2018, 13:33

Datenbankzugriffe optimieren
- richtiger Index genutzt?
- nur die benötigten Felder übertragen?
- sortierung auf db ausgelagert? (wenn nötig)
- FAE und Ranges sortieren/duplikate löschen

Itab-Zugriffe optimiert
- sortierte oder noch besser hashed tabellen nutzen
- in loops mit fiel-symbols arbeiten
- keine sorts und db-zugriffe in einem loop
- sortierte Schlüssel für where-bedingungen bei loops verwenden und keine OR-Verknüpfungen

vielen Dank für deine Anhaltspunkte. Ich hab jetzt schon mal auf Into Table abgeändert. Hat vielleicht ein bisschen was gebracht, aber nicht wirklich merklich. Ich teste die Zeit mit get run time field. Leider sind dort die Zeiten aufgrund der Auslastung auch unterschiedlich, deshalb kann es auch nur grob bestimmt werden, ob es nun wirklich schneller geworden ist, lässt sich wenn dann nur minimal festhalten.

Bin gerade mal dabei deine anderen Punkte am abarbeiten.
Bright4.5
ForumUser
 
Beiträge: 95
Registriert: 17.08.2018, 18:23
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Dele » 10.12.2018, 14:30

- sortierung auf db ausgelagert? (wenn nötig)

Wie ist das bitte zu verstehen?
Ist es nicht mehr so, dass man die DB (als Flaschenhals) weitestgehend entlasten sollte? Außer man kann z.B. durch Aggregatfunktionen (SUM) die Anzahl der Ergebnismenge deutlich reduzieren.
Dele
Specialist
 
Beiträge: 307
Registriert: 06.05.2005, 11:07
Dank erhalten: 47 mal

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon ewx » 10.12.2018, 14:42

Dem Flaschenhals ist es egal, ob die Daten sortiert oder unsortiert hindurch gehen... ;)

Die Datenbankzugriffe + Datenmenge sollte minimiert werden.
Ansonsten darf man die Datenbank gerne arbeiten lassen...

Für diese Nachricht hat ewx einen Dank bekommen :
Legxis
ewx
Top Expert
 
Beiträge: 3839
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 322 mal

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon nickname8 » 10.12.2018, 14:45

Mit dem Code-To-Data oder auch Code-Pushdown Ansatz geht es darum, der Datenbank so viel Arbeit wie möglich zu überlassen.
Die DB ist ja - kezerisch gesprochen - nur ein Datengrab. Die CPU hat im Gegensatz zum Applikationsserver vergleichsweise wenig zu tun. Da ist der Flaschenhals eher der Datendurchsatz als die CPU.
nickname8
ForumUser
 
Beiträge: 78
Registriert: 18.07.2015, 08:22
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Dele » 10.12.2018, 14:57

Ansonsten darf man die Datenbank gerne arbeiten lassen...

Klar, dafür ist sie ja da.
Aber man sollte sie nicht unnötig belasten. Man hat nur einen DB-Server und ggf. mehrere Applikation-Server. Verteilung der Last ist immer gut. Wird der DB-Server mit Aufgaben beschäftigt, die genauso gut auch auf den Applikation-Servern gemacht werden können, dann belastet man die zentrale DB-Instanz als potentiellen Flaschenhals unnötig. Sortierung ist da ein gutes Beispiel.
Dele
Specialist
 
Beiträge: 307
Registriert: 06.05.2005, 11:07
Dank erhalten: 47 mal

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon ewx » 10.12.2018, 15:09

Wahrscheinlich können wir da tagelang herumdiskutieren, was wann wie unter welchen Umständen besser ist.
Letztendlich tut es sich wahrscheinlich nicht viel, ob die Tabelle von der DB oder von der Applikation sortiert wird. Kommt wahrscheinlich sehr auf die Größe drauf an.
Lastverteilung: Deswegen soll die DB ja IMHO gerne sortieren. Die Applikation übernimmt ja bereits die Last der Verarbeitung... :D
ewx
Top Expert
 
Beiträge: 3839
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 322 mal

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon Bright4.5 » 10.12.2018, 15:54

So.

Also Feldsymbole bei Loops benutze ich.

Die Tabellen sind sortiert und Duplikate gelöscht.

Hashed-Tabellen funktioniert leider nicht, da ich Indexoperationen im Programm vollziehe.

Es verursacht vor allem an dieser Stelle einen Timeout:

SELECT p~lifnr p~laufd p~vblnr p~name1 p~pstlz
p~stras p~zbnkn p~zswif
FROM reguh AS p
INNER JOIN regup AS k
ON p~lifnr = k~lifnr
INTO TABLE it_regh_up
FOR ALL ENTRIES IN it_regp_kp
WHERE k~xblnr = it_regp_kp-xblnr
AND k~hkont NOT IN r_hkont
AND p~saknr = it_regp_kp-saknr
AND p~dmbtr <= IN so_ibst.

Dieses For all entries vielleicht umstellen/ersetzen???
Bright4.5
ForumUser
 
Beiträge: 95
Registriert: 17.08.2018, 18:23
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon nickname8 » 10.12.2018, 16:11

Hm, da sehe ich mehrere Probleme:
- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf
- p~saknr und p~dmbtr sind nicht Bestandteil irgendeines Schlüssels in der REGUH

Vielleicht gibts einen FuBa der optimiert auf die Tabelle REGUP zugreift.

Ich weiß nicht ob du mit einer Optimierung von FAE weiterkommst.
Kannst es ja versuchen: FAE sortieren und Duplikate löschen, bzw. zwei Ranges bauen. Aber für mich sieht es nach einem ziemlichen FULL TABLE SCAN aus...

Hat der Select schonmal im Produktivsystem funktioniert? Oder bisher immer in einen Timeout gelaufen.
Wie lange läuft der im Hintergrundmodus?
nickname8
ForumUser
 
Beiträge: 78
Registriert: 18.07.2015, 08:22
Dank erhalten: 10 mal
Ich bin: Entwickler/in

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitragvon DeathAndPain » 10.12.2018, 19:06

nickname8, Du solltest Deine Überzeugungen unbedingt sorgsamer mit der Realität abgleichen, bevor Du sie im Brustton der Überzeugung vorträgst. Was Du hier alles an zweifelhaften Behauptungen aufgestellt hast, geht auf keine Kuhhaut. Damit verunsicherst Du andere Anwender und schickst sie auf falsche Gleise.

nickname8 hat geschrieben:- sortierte oder noch besser hashed tabellen nutzen

Ich habe auch mal geglaubt, dass hashed-Tabellen besser seien. Bis ich mir irgendwann mal die Mühe gemacht habe, ein Testprogramm zu schreiben und die Performance zu messen. (Irgendwo hier gibt es noch den Thread, in dem ich das Programm und meine Messergebnisse vorgestellt habe.) Das Ergebnis war, dass das Füllen der Hashtabelle (wohl wegen der Berechnung der Hashes) um so viel langsamer war, dass man hinterher Abertausende von Suchvorgängen brauchen würde, damit sich dieser Nachteil gegenüber einer sorted table amortisiert. Dabei nützt es auch nichts, von besonders großen Tabellen auszugehen. Bei denen ist der (geringe) Suchvorteil der hashed table zwar größer, dafür sind aber auch entsprechend mehr Hashes beim Befüllen der Tabelle zu berechnen.

Die Zahlen waren dergestalt, dass ich zu dem Ergebnis gekommen bin, dass sich abgesehen von exotischen Extremfällen hashed tables in realitätsnahen Programmen niemals lohnen.


nickname8 hat geschrieben:
Tommy hat geschrieben:anscheinend wird das irgendwie gepuffert...

Wird es.

https://ibb.co/HGR3XmF

Die ABAP-Tabellenpufferung hat damit gar nichts zu tun, die ist nämlich nur bei Tabellen überschaubarer Größe (typischerweise Customizingtabellen) aktiviert, nicht bei den Anwendungsdatentabellen, auf die man in seinen Programmen meist zugreift. Der hier beschriebene Effekt tritt jedoch auch bei letzteren auf. Ursache ist, dass die Datenbanken selber auch puffern. Wer oft hintereinander auf dieselbe Tabelle oder gar dieselben Sätze der Tabelle zugreift, bekommt die späteren Zugriffe wesentlich schneller erledigt. Das ist nicht so schnell wie die ABAP-Tabellenpufferung, die SAP-serverseitig im Hauptspeicher erfolgt und schon gar nicht so schnell wie eine durchdacht programmierte Pufferung in einer sortierten internen Tabelle, aber es ist allemal drastisch schneller als ein erstmaliger Zugriff.

Leider versaut einem dieses Datenbank-Caching weitgehend die Messmöglichkeiten. Es ist nämlich nicht nur so, dass der zweite SELECT dem ersten gegenüber im Vorteil ist. Startet man das Messprogramm ein weiteres Mal, dann sind die Tabellenzeilen oft immer noch gepuffert, so dass die Datenbank beide Anfragen aus ihrem Puffer beantwortet und man keine sinnvollen Messergebnisse bekommt. Erschwerend kommt hinzu, dass die Ausführungszeiten stark schwanken, was auch mit der Serverlandschaft zu tun hat. Meist handelt es sich ja um gehostete Server in virtuellen Umgebungen, bei denen mehrere virtuelle Server auf einer physischen Maschine sitzen. Da kann die Last von einer anderen virtuellen Maschine in einer Millisekunde hoch und in der nächsten gering sein, was einem die Messergebnisse verhagelt. Das kann man nur ausgleichen, indem man das Messprogramm oft hintereinander startet und die Ergebnisse mittelt. Leider wird man damit aber erst recht Opfer des Datenbankcachings. (Wenn jemand einen Datenbank-Hint für Sybase kennt, mit dem man dieses Caching zu Messzwecken umgehen kann, immer her damit.)

Dass der INTO TABLE, der die ganze von der Datenbank gelesene Datenstruktur platsch in die Zielstruktur schreibt, schneller ist als ein INTO CORRESPONDING FIELDS OF TABLE, liegt auf der Hand. Nach meiner Erfahrung ist der Unterschied aber so gering, dass ich noch nie einen Performanceunterschied wahrgenommen habe, wenn geänderte Programmanforderungen mich gezwungen habe, einen INTO TABLE in einen INTO CORRESPONDING FIELDS OF TABLE umzubauen. Was da an zusätzlicher Rechenzeit notwendig ist, ist ja rein im ABAP. Und wenn ich mir anschaue, was der durchschnittliche Programmierer sonst so an Performance verschenkt, etwa mit sinnlosen Befehlen... Sehr häufig liest man vor dem SELECT beispielsweise einen CLEAR bzw. REFRESH auf die zu füllende Tabelle. Eine völlig überflüssige Anweisung, da INTO TABLE (egal ob mit oder ohne CORRESPONDING) sowieso immer erst die Zieltabelle leert. Klar ist der Performanceverlust durch solch CLEAR gering und wird in aller Regel unterhalb der Wahrnehmungsschwelle liegen. Aber wenn wir über den Performancenachteil von INTO CORRESPONDING FIELDS OF TABLE gegenüber INTO TABLE reden, dann muss es auch erlaubt sein, sowas auf den Tisch zu bringen.

nickname8 hat geschrieben:- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf

Auf was für einem alten Release sitzt Du? Die SAP stellt Clustertabellen nach und nach auf transparente Tabellen um, und auf meinem 7.50 ist die REGUP auch eine transparente Tabelle. Weitere Indizes sind trotzdem nicht darauf definiert, aber das könnte man notfalls selber machen. Sollte man natürlich möglichst vermeiden, weil es bei großen Tabelle viel Speicherplatz und auch etwas Rechenzeit kostet.

@Bright4.5: Dein SELECT ist eine ziemliche Katastrophe. Nicht nur, dass Du keinen auf den Tabellen REGUP und REGUH definierten Datenbankindex auch nur ansatzweise nutzt, Du verknüpfst die beiden Tabellen in Deinem JOIN auch nicht sinnvoll. Die haben ja zum größten Teil den gleichen Primärschlüssel. Zumindest diese Felder sollten alle in den ON-Teil des Joins rein, und dann sinnvolle Indexfelder in die WHERE-Bedingung. Ich möchte wetten, dass Performance nicht Dein einziges Problem ist, sondern dass dieser Join, wenn er denn mal fertig werden würde, Dir ohne Ende unerwünschte Kreuzprodukte (also im Sinne Deiner Aufgabenstellung falsche Ergebnisse) zurückliefern würde.

Ich kenne die beiden Tabellen nicht, da sie zu Modulen gehören, in denen ich nicht zu Hause bin, aber dennoch behaupte ich, dass die SAP sich was dabei gedacht hat, als sie die Primärschlüssel und sonstigen Tabellenindizes dieser Tabellen so festgelegt hat, wie sie festgelegt sind. Du solltest daher Deine Anforderung überprüfen, ob sie sich nicht damit in Einklang bringen lässt.

Wenn es gar nicht anders geht und der Zugriff unbedingt über diese Schlüsselfelder erfolgen soll, dann wäre der einzig mögliche Weg, die beiden Tabellen (möglichst reduziert auf die für Deinen Zugriff relevanten Spalten) komplett in interne Tabellen einzulesen, die Deiner Anforderung entsprechend sortiert sind, so dass Dein Programm gewissermaßen seinen eigenen Index im Hauptspeicher aufbaut. Danach würdest Du dann darüber loopen und hättest dank Deiner durchdachten internen Tabellenschlüsseldefinition eine vernünftige Zugriffszeit. Kostet natürlich Hauptspeicher, solch Tabellenkomplettpufferung in eigener interner Tabelle, wobei Du auch hier optimieren kannst, indem Du keine Zeilen in die Puffertabelle einliest, die Du auf keinen Fall brauchen wirst (z.B. solche aus längst vergangenen Jahren; das hängt vom Anwendungsfall ab). Sobald Du einen Suchzugriff über diese Spalten in mehr als einem Programm brauchst, ist die Anlage eines Datenbankindex angezeigt.

Für diese Nachricht hat DeathAndPain einen Dank bekommen :
Legxis
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Nächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Umrechnung Stück in KG
vor 2 Stunden von Nordlicht 0 Antw.
gelöst Sel.Screen in Subscreen - VA06
vor 16 Stunden von bapimueller 2 Antw.
gelöst Prüfen Konfiguration Kundenauftrag gene Type
vor 22 Stunden von mfromg 0 Antw.
Auswertung Orders erhalt per Mail oder FAX oder beides
vor 16 Stunden von ewx 2 Antw.
SAP und Gamification
Gestern von ewx 1 Antw.

  Ähnliche Beiträge beta
„INTO CORRESPONDING FIELDS OF TABLE“ <--was ist falsch ?
19.01.2012, 13:32 von RockyAM 2 Antw.
INTO CORRESPONDING FIELDS OF
06.08.2008, 14:37 von nikibert 2 Antw.
append mit corresponding fields?
26.09.2012, 14:21 von Unit605 4 Antw.
At New <field> gibt immer field trotz gelichen fields
02.05.2012, 12:45 von Murdock 5 Antw.
Table connection
06.12.2003, 14:19 von Juergen 1 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder