OpenSQL: Profilparameter des SELECT FOR ALL ENTRIES-Befehls

Autor: Alexander Depold | 5. August 2015

15 | #Profilparameter

Die OpenSQL-Syntax umfasst einige Sprachelemente, welche nicht zur klassischen SQL-Syntax gehören. Diese werden von der Datenbankschnittstelle in die jeweilige native Syntax übersetzt. Hierbei wird die Art der Umwandlung von Profilparametern beeinflusst. Im Folgenden werden die Profilparameter und ihre Bedeutung bezüglich der FOR ALL ENTRIES-Anweisung (FAE) vorgestellt.

Profilparameter mit der RZ11-Transaktion bei OpenSQL

Die vorgestellten Profilparameter können über die Transaktion RZ11 mit den Werten 0, 1 und -1 belegt werden. Bei der Angabe von -1 wird in Abhängigkeit des Datenbanksystems mit der OpenSQL-Syntax ein Default-Wert verwendet. Diese wird unter “Aktueller Wert” angezeigt.

OpenSQL

Die Art der Umsetzung wird über die Parameter rsdb/prefer_union_all, rsdb/prefer_join und
rsdb/prefer_in_itab_opt gesteuert und lässt sich mit Hilfe des SQL-Trace (ST05) nachvollziehen.
Sind all diese Parameter mit Null gepflegt, wird die FAE-Anweisung für jede Tabellenzeile durch eine OR-Verknüpfung realisiert. Das heißt eine Abfrage der Form

SELECT ... FOR ALL ENTRIES IN lt_data WHERE val = lt_data-val.

wird in

SELECT ... WHERE val = lt_data[1]-val
OR lt_data[2]-val
OR ... 
OR t_data[n]-val.

übersetzt. Hierbei entspricht lt_data[i]-val gerade dem zugehörigen Eintrag in der i-ten Zeile.

Ist der Parameter rsdb/prefer_union_all gesetzt, ergibt sich für das native Statement folgende Ausgabe:

SELECT ... WHERE  val = lt_data[1]-val UNION ALL
SELECT ... WHERE  val = lt_data[2]-val UNION ALL
....
SELECT ... WHERE  val = lt_data[n]-val.

Der Parameter rsdb/prefer_join erzeugt eine Abfrage, welche vergleichbar einem Join mit einer internen Tabelle ist und kann ab Kernelversion 7. 00 für die Datenbankplattformen DB6 (DB2 UDB) und “MS SQL Server” sowie ab Kernelversion 7.10 für Oracle genutzt werden. Der Parameter übersteuert hierbei rsdb/prefer_union_all.

Bei Anweisungen, welche nur eine Bedingung an die FAE-Tabelle stellen, kommt der Parameter rsdb/prefer_in_itab_opt zum Tragen. Er erzeugt ein SQL-Statement der Form

SELECT ... WHERE val IN ( lt_data[1]-val, lt_data[2]-val, ...,  lt_data[n]-val ).

und übersteuert ggf. die vorhergehenden Parameter.

SAP Basis Berater - gesamte Projekte oder Berater auf Zeit

Sie suchen Unterstützung durch SAP Basis Berater? Wir bieten mehr als nur einen gewöhnlichen Berater auf Zeit. Informieren Sie sich über Ihre Vorteile!

Weitere Parameter

Neben den Parametern für die Beschreibung der Umsetzung stehen noch weitere Parameter zur Einschränkung der Größe der SQL-Anweisung zur Verfügung. Diese geben die maximale Anzahl der zu verarbeitenden Zeilen aus der Treibertabelle an. Überschreitet die Tabelle diese Grenze, werden entsprechend mehre SQL-Statements erzeugt und nach der Verarbeitung zusammengefasst. Dies dient zum einem der optimierten Abfrage, da zum Beispiel einige Datenbanksystem ab einer bestimmten Anzahl an OR-Verknüpfungen einen Full-Table-Scan durchführen anstatt auf einen Index zurückzugreifen. Andererseits schützt es vor einem zu großem SQL-Query-String (anhängig von der zugrundeliegenden Datenbank), welcher zu einem Laufzeitfehler (DBSQL_STMNT_TOO_LARGE) führt. Dieser tritt zum Beispiel bei der Verwendung sehr großer Range-Tabellen in der WHERE-Abfrage auf.

Die Parameter lauten rsdb/max_blocking_factor (OR, UNION, JOIN) bzw. rsdb/max_in_blocking_factor (IN). Ab Kernelversion 7.20 steht darüber hinaus noch der optionale Parameter rsdb/max_union_blocking_factor (UNION) zur Verfügung.

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 800 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Parameter zur Performanceoptimierung

In Abhängigkeit von der Datenbank kann zur Performanceoptimierung noch der Parameter rsdb/prefer_fix_blocking gesetzt werden. Dieser bewirkt, dass bei der Blockbildung der SQL-Abfragen das letzte Statement mit identischen Bedingungen bis zu maximal Anzahl aufgefüllt wird. Diese werden von Datenbank selbst ignoriert, können aber im SAP-Cursor-Cache durch die einheitliche Blockgröße zu einer erhöhten Performance führen. Neben der oben erwähnten maximalen Blockgröße kann noch eine zweite alternative Blockgröße über die Parameter rsdb/min_blocking_factor, rsdb/min_in_blocking_factor und rsdb/min_union_blocking_factor (ab 7.20) gesetzt werden. Ist also das Verwenden einer festen Blockgröße eingestellt, wird die SQL-Abfrage zur maximalen oder ggf. minimalen Blockgröße aufgefüllt.

Hier noch einmal alle Profilparameter der OpenSQL-Syntax im Überblick:

rsdb/prefer_union_all Umsetzung in UNION-Statement, sonst OR
rsdb/prefer_join Umsetzung in JOIN-Statement
rsdb/prefer_in_itab_opt Umsetzung in IN-Statement (bei einer Bedingung)
rsdb/max_blocking_factor Standardblockgröße OR/UNION/JOIN
rsdb/max_in_blocking_factor Standardblockgröße IN-Statement
rsdb/max_union_blocking_factor Standardblockgröße UNION (ab 7.20)
rsdb/prefer_fix_blocking Feste Blockgröße auf letztes Statement (auffüllen)
rsdb/min_blocking_factor Alternative Blockgröße OR/UNION/JOIN
rsdb/min_in_blocking_factor Alternative Blockgröße IN
rsdb/min_union_blocking_facto Alternative Blockgröße UNION (ab 7.20)

Im Normalfall bedarf es keiner Anpassung der Parameter, da sie über die Default-Werte optimal an das jeweilige Datenbanksystem angepasst sind. Das Verständnis hilft jedoch bei der Performanceoptimierung vom Datenbankabfragen.

Wie sind Ihre Erfahrungen zu dem Setzen von Datenbankspezifischen Profilparametern?

Sie benötigen Unterstützung bei der Umsetzung? Unser Autor ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Basis


Artikel war hilfreichArtikel empfehlen


Dieser Beitrag ist auch als Download verfügbar:
Alexander Depold

Autor

Alexander Depold

B. Sc. Applied Computing

Fragen? Anmerkungen?
Kontaktieren Sie mich

Kommentar verfassen


Unsere Top-Downloads

Kontaktieren Sie uns!
Renate Burg Kundenservice