INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Getting started ... Alles für einen gelungenen Start.
45 Beiträge • Seite 1 von 3 (current) Nächste
45 Beiträge Seite 1 von 3 (current) Nächste

INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Bright4.5 (Specialist / 265 / 21 / 1 ) »
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?

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


Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Tommy Nightmare (ForumUser / 28 / 5 / 1 ) »
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

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
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 :-)

Folgende Benutzer bedankten sich beim Autor nickname8 für den Beitrag:
Legxis


Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
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 :)

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Tommy Nightmare (ForumUser / 28 / 5 / 1 ) »
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...

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
Tommy Nightmare hat geschrieben:anscheinend wird das irgendwie gepuffert...
Wird es.

https://ibb.co/HGR3XmF

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Bright4.5 (Specialist / 265 / 21 / 1 ) »
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.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Dele (Specialist / 307 / 4 / 47 ) »
- 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.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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...

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
Legxis


Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
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.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Dele (Specialist / 307 / 4 / 47 ) »
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.

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von Bright4.5 (Specialist / 265 / 21 / 1 ) »
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???

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
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?

Re: INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis


Vergleichbare Themen

2
Antw.
12998
Views
„INTO CORRESPONDING FIELDS OF TABLE“ <--was ist falsch ?
von K0RN » 17.01.2012 16:18 • Verfasst in ABAP® für Anfänger
1
Antw.
4720
Views
sorted table, hashed table: Übergabe Workarea -> Performa
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
5
Antw.
9472
Views
standard table vs. sorted table
von ralf.wenzel » 31.07.2014 12:49 • Verfasst in ABAP® Core
11
Antw.
4836
Views
table to CSV
von Abapsocke » 18.02.2019 11:29 • Verfasst in ABAP® für Anfänger
1
Antw.
1880
Views
Table Control
von amjahid » 22.11.2007 13:57 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

Zugriff auf Daten via Webdav
vor 13 Minuten von msfox 2 / 33
Interne Tabelle
vor 17 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

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.

Aktuelle Forenbeiträge

Zugriff auf Daten via Webdav
vor 13 Minuten von msfox 2 / 33
Interne Tabelle
vor 17 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141