Alternative For All Entries

Getting started ... Alles für einen gelungenen Start.
24 Beiträge / Vorherige Seite 2 von 2 (current)
24 Beiträge Vorherige Seite 2 von 2 (current)

Re: Alternative For All Entries

Beitrag von a-dead-trousers (Top Expert / 3199 / 81 / 792 ) » 14. Feb 2019 09:20

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.
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: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.
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.
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.07
Basis: 7.40


Re: Alternative For All Entries

Beitrag von DeathAndPain (Top Expert / 1014 / 115 / 223 ) » 14. Feb 2019 09:52

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.
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.)

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.
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.
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.

Re: Alternative For All Entries

Beitrag von Daniel (Specialist / 308 / 67 / 39 ) » 14. Feb 2019 12:18

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).

Re: Alternative For All Entries

Beitrag von DeathAndPain (Top Expert / 1014 / 115 / 223 ) » 14. Feb 2019 13:03

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&'
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.

Re: Alternative For All Entries

Beitrag von Daniel (Specialist / 308 / 67 / 39 ) » 14. Feb 2019 13:22

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.

Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
deejey


Re: Alternative For All Entries

Beitrag von A6272 (Specialist / 114 / 1 / 9 ) » 14. Feb 2019 17:00

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

Re: Alternative For All Entries

Beitrag von DeathAndPain (Top Expert / 1014 / 115 / 223 ) » 15. Feb 2019 11:29

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).

Re: Alternative For All Entries

Beitrag von A6272 (Specialist / 114 / 1 / 9 ) » 15. Feb 2019 13:16

Ja, die 2 Tabellen sind ordentlich über Primärschlüssel verknüpft, aber was ist mit der where Bedingung?

LFA1~ERDAT in ... ?

Re: Alternative For All Entries

Beitrag von DeathAndPain (Top Expert / 1014 / 115 / 223 ) » 15. Feb 2019 13:25

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.

Vorherige Seite 2 von 2 (current)

Aktuelle Forenbeiträge

In einer Methode auf Rangetabelle zugreifen
vor 6 Stunden von DeathAndPain 5 / 74
Elstam: IDnr mehrfach für die Personalnummer
vor 8 Stunden von missforgotten 6 / 280
Steuerprüfer GDPDU - Daten rutschen um eine Zeile
vor 8 Stunden von missforgotten 1 / 19
OBN im NWBC ohne Popup
Gestern von msfox 2 / 54
Business Partner Konzept
Gestern von waltersen 4 / 293

Unbeantwortete Forenbeiträge

Steuerprüfer GDPDU - Daten rutschen um eine Zeile
vor 8 Stunden von missforgotten 1 / 19
MD14 Felder einblenden Umsetzung Planauftrag
Gestern von Thomas R. 1 / 30
Verursachervormerkung OCM manuell anlegen
vor einer Woche von Aba 1 / 131
Auflösen MILL_OC - Auftragszusammenfassung
vor 2 Wochen von tofralu 1 / 115