Alternative For All Entries
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Okay, das wusste ich nicht. Ich hab mir immer gedacht das hängt mit der "maximalen" Länge zusammen die ein nativ SQL-Statement werden darf und 5 schien mir ein guter Wert zu sein, wenn man alle möglichen Kombinationen aus I/E und BT, EQ, NE usw. berücksichtigt.DeathAndPain hat geschrieben:Nicht "defaultmäßig", sondern das ist die von der SAP empfohlene Einstellung für Oracle. Der Grund für diese Empfehlung (bzw. generell dafür, weshalb es da überhaupt einen Grenzwert gibt) wird irgendwo in den SAP-Hinweisen auch erwähnt: Ab einer gewissen Menge übergebener Einzelwerte entscheidet sich die Optimierer der Datenbank nicht mehr dafür, den Index zu verwenden, sondern rast sequenziell durch die Tabelle, um auf diese Weise alle angefragten Einzelwerte abzugrasen. Offenbar ist dies jedoch deutlich ineffizienter, als für jeden Einzelwert den Index zu nutzen, weswegen es besser ist, die FOR ALL ENTRIES-Anfrage in so viele Teilanfragen aufzuteilen, dass der Optimierer jede einzelne, mit dem IN-Operator übertragene Teilanfrage noch über den Index abwickelt. Mit anderen Worten: SAP hat Gründe, weshalb sie das so empfehlen.
Bei Ranges die nur I und EQ beinhalten, hat unsere alte Oracle-DB (jetzt haben wir HANA) mit "IN (...)" gearbeitet und auch bei großen Mengen immer den Index gezogen. Daher hab ich angefangen große FOR ALL ENTRIES nach Möglichkeit in Ranges zu packen und es hatte signifikante Performanceverbesserungen gebracht. Aber möglich, dass unser Baisis-Betrieb Oracle anders konfiguriert hatte, wenn die Index-Findung, so wie du sagst, db-abhängig ist.DeathAndPain hat geschrieben:RANGES gibt es in Native SQL genauso wenig wie FOR ALL ENTRIES IN. ABAP hat also gar keine andere Wahl, als eine RANGES-Tabelle auch in passende Native SQL-Statements für die Datenbank zu übersetzen. Und dabei gibt es zwei Möglichkeiten: Entweder ABAP hält sich auch dabei an die Systemparameter, was dann zum FOR ALL ENTRIES IN äquivalent wäre, oder es beachtet die Systemparameter nicht, dann gibt es datenbankseitig einen sequenziellen Scan ohne Index, was aus Performancesicht die schlechtmöglichste Lösung ist.
Du kannst hier also nichts gewinnen, sondern bestenfalls nichts verlieren.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Wie gesagt, bei Sybase (womit wir arbeiten) ist der empfohlene Wert 128. Damit sinkt dann die Zahl der einzelnen Datenbankanfragen im Vergleich zum einzeln Durchhecheln mit SELECT SINGLE rasch mal auf unter 1%. (Sybase hat dafür andere Nachteile, und wie die Gesamtperformance von Sybase gegenüber Oracle ist, maße ich mir sowieso nicht an zu beurteilen. Einen Gesamtperformancegewinn hat der Umstieg von Oracle auf Sybase bei uns damals jedenfalls nicht gebracht.)Okay, das wusste ich nicht. Ich hab mir immer gedacht das hängt mit der "maximalen" Länge zusammen die ein nativ SQL-Statement werden darf und 5 schien mir ein guter Wert zu sein, wenn man alle möglichen Kombinationen aus I/E und BT, EQ, NE usw. berücksichtigt.
Auf jeden Fall stelle ich fest, dass die Performance exzellent ist, wann immer ich FOR ALL ENTRIES in verwende, weswegen ich mich bemühe, dies möglichst häufig zu tun und benötigte Daten in internen Puffertabellen zwischenzuspeichern, bevor ich Einzelwerte daraus lese. Hauptspeicher ist ja heute kein Problem mehr. Trotzdem bemühe ich mich, diese Puffertabellen auf die für mich relevanten Spalten zu beschränken (also kein SELECT * zu puffern) und im Programmcode nach der Ermittlung der eigentlich benötigten Ergebnisdaten, also wenn ich die Puffertabelle nicht mehr brauche, einen FREE-Befehl abzusetzen. Dann ist der Hauptspeicher schon wieder frei, während der Benutzer das ALV begutachtet (oder was immer das jeweilige Programm da tun mag).
Wie gesagt, ich weiß nicht, wie ABAP eine RANGES-Tabelle mit lauter Einzelwerten in Native SQL umsetzt, aber die können da ja auch nur mit Wasser kochen. Interessanterweise kann ich mich erinnern, mal ausgetestet zu haben bis wieviel abgefragten Einzelwerten der FOR ALL ENTRIES in schneller ist als ein Kompletteinlesen der Datenbanktabelle ohne entsprechende WHERE-Bedingung (was ja nur einen einzigen, freilich dicken, Datenbankzugriff bedeutet). Ganz genau kann ich mich an das Ergebnis nicht mehr erinnern, aber ich weiß, dass der Wert bedeutend höher lag, als ich angenommen hätte. Ich glaube, wenn Du 70% der Zeilen der Datenbanktabelle über FOR ALL ENTRIES IN mit Primärschlüssel einliest, dann geht das immer noch schneller, als wenn Du auf eine WHERE-Bedingung verzichtest und alles einliest. Wobei das, wie gesagt, für Sybase gilt. Keine Ahnung, wie das bei Oracle aussehen würde.
Ich kann nur wiedergeben, was mir aus den einschlägigen SAP-Hinweisen zum Thema "Systemparametereinstellung für den IN-Operator" in Erinnerung ist. Mittlerweile verblasst meine Erinnerung daran auch etwas.Bei Ranges die nur I und EQ beinhalten, hat unsere alte Oracle-DB (jetzt haben wir HANA) mit "IN (...)" gearbeitet und auch bei großen Mengen immer den Index gezogen. Daher hab ich angefangen große FOR ALL ENTRIES nach Möglichkeit in Ranges zu packen und es hatte signifikante Performanceverbesserungen gebracht.
Bei Selektionen mit FOR ALL ENTRIES kommt es auf
verschiedene Parameter an, das kann man nur ausprobieren.
Dazu gibt es einen Hint:
%_HINTS ORACLE '&max_in_blocking_factor 500&'
Ich habe meistens einen erhebliche Gewinn erreicht in dem
ich den Wert hochgesetzt habe. Die Zugriffe gingen aber
immer über den Index (teilweise auch mit HINT erzwungen).
verschiedene Parameter an, das kann man nur ausprobieren.
Dazu gibt es einen Hint:
%_HINTS ORACLE '&max_in_blocking_factor 500&'
Ich habe meistens einen erhebliche Gewinn erreicht in dem
ich den Wert hochgesetzt habe. Die Zugriffe gingen aber
immer über den Index (teilweise auch mit HINT erzwungen).
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Das ist doch einer von den Systemparametern aus dene SAP-Hinweisen. Wenn der richtig gesetzt ist, dann sollte man doch eigentlich nicht noch einen Datenbank-Hint brauchen.Bei Selektionen mit FOR ALL ENTRIES kommt es auf
verschiedene Parameter an, das kann man nur ausprobieren.
Dazu gibt es einen Hint:
%_HINTS ORACLE '&max_in_blocking_factor 500&'
Der System-Parameter gilt für jeden Zugriff.
Das passt aber nicht immer. Deshalb kann man
mit dem Hint einen passenden Wert in Abhängigkeit
von jeweiligen Select angeben.
Das passt aber nicht immer. Deshalb kann man
mit dem Hint einen passenden Wert in Abhängigkeit
von jeweiligen Select angeben.
Hallo,
die Frage des Erstellers war "Hilfe es ist lahm" und er schiebt es auf For All Entries (ist eigentlich nur Ablekung).
Er selektiert nach LFA1~ERDAT --> Also standardmäßig ist da kein Index drauf. Keine Ahnung, wie groß die Tabelle üblicher weise ist, aber eine Selektion nach ERDAT auch ohne Join und mit nur einem Wert dürfte schon nicht schnell sein.
Ein passender Index könnte Wunder bewirken...
Viele Grüße
Alex
die Frage des Erstellers war "Hilfe es ist lahm" und er schiebt es auf For All Entries (ist eigentlich nur Ablekung).
Er selektiert nach LFA1~ERDAT --> Also standardmäßig ist da kein Index drauf. Keine Ahnung, wie groß die Tabelle üblicher weise ist, aber eine Selektion nach ERDAT auch ohne Join und mit nur einem Wert dürfte schon nicht schnell sein.
Ein passender Index könnte Wunder bewirken...
Viele Grüße
Alex
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Das habe ich auch erst gedacht, aber es stimmt nicht, wenn Du Dir seinen SELECT genauer anschaust. Er hat ja die ON-Bedingung ON t~tabkey = k~lifnr drin. Die ist zwar semantisch verdreht (das k~lifnr sollte links und das andere rechts stehen), stellt aber gleichwohl eine Einschränkung auf LIFNR dar. Damit ist der Primärschlüssel sauber selektiert. Haubi hat auch erklärt, dass diese Verdrehung nicht nachteilhaft sei, weil der Datenbankoptimierer es ausgleichen würde (ich würde dennoch mal versuchen, es richtig herum zu schreiben. Minimal steigt die Verständlichkeit des Statements).
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Da brauchst Du es ja nicht. Die Datenbank soll Einträge aus der TIBAN suchen, ordentlich mit dem Feld IBAN eingegrenzt, auf dem die TIBAN einen Index hat, und zu jedem Suchergebnis soll zusätzlich aus der LFA1 die (eindeutige) Zeile mit dem entsprechenden Lieferanten gelesen werden. Was willst Du auf der LFA1 noch weiter einschränken, wenn über das ON bereits das einzige Primärschlüsselfeld der Tabelle auf Gleichheit geprüft wird? Damit wirst Du zu jeder Ergebniszeile der TIBAN (maximal) eine Zeile in der LFA1 erhalten. Das ist ja genau der Aufbau eines klassischen Joins: Lies eine Einstiegstabelle, und lies dann zu den gefundenen Suchergebnissen Sekundärtabellen basierend auf der unter ON definierten Verknüpfungsbedingung. Optional kannst Du im WHERE-Teil noch weitere Einschränkungen für die Sekundärtabellen angeben. Das brauchst Du aber nicht, und beim ganz klassischen JOIN tust Du es auch nicht.
Gebraucht wird die zusätzliche ERDAT-Prüfung ja ohnehin nur, um das ganze Suchergebnis zu verwerfen, wenn diese (eindeutige) LFA1-Zeile kein hinreichend hohes ERDAT hat. Da die Zeile in der LFA1 durch die LIFNR bereits eindeutig spezifiziert ist, stellt die Prüfung auf ERDAT keine zusätzliche Präzisierung mehr dar, sondern dient nur dazu, gefundene Suchergebnisse ggf. zu verwerfen. Genau aus diesem Grunde habe ich ja weiter oben als alternative Lösung eine Subquery mit EXISTS vorgeschlagen, die letztlich dasselbe tut.
Gebraucht wird die zusätzliche ERDAT-Prüfung ja ohnehin nur, um das ganze Suchergebnis zu verwerfen, wenn diese (eindeutige) LFA1-Zeile kein hinreichend hohes ERDAT hat. Da die Zeile in der LFA1 durch die LIFNR bereits eindeutig spezifiziert ist, stellt die Prüfung auf ERDAT keine zusätzliche Präzisierung mehr dar, sondern dient nur dazu, gefundene Suchergebnisse ggf. zu verwerfen. Genau aus diesem Grunde habe ich ja weiter oben als alternative Lösung eine Subquery mit EXISTS vorgeschlagen, die letztlich dasselbe tut.
Vergleichbare Themen
1
Antw.
Antw.
1501
Views
Views
3
Antw.
Antw.
1925
Views
Views
1
Antw.
Antw.
1973
Views
Views
1
Antw.
Antw.
2407
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.