OpenSQL: Profilparameter des SELECT FOR ALL ENTRIES-Befehls

Autor: Alexander Depold | 5. August 2015

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

Parameter zur Performanceoptimierung

Kostenloses E-Book
Unser E-Book zum Thema SAP Basis

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_allUmsetzung in UNION-Statement, sonst OR
rsdb/prefer_joinUmsetzung in JOIN-Statement
rsdb/prefer_in_itab_optUmsetzung in IN-Statement (bei einer Bedingung)
rsdb/max_blocking_factorStandardblockgröße OR/UNION/JOIN
rsdb/max_in_blocking_factorStandardblockgröße IN-Statement
rsdb/max_union_blocking_factorStandardblockgröße UNION (ab 7.20)
rsdb/prefer_fix_blockingFeste Blockgröße auf letztes Statement (auffüllen)
rsdb/min_blocking_factorAlternative Blockgröße OR/UNION/JOIN
rsdb/min_in_blocking_factorAlternative Blockgröße IN
rsdb/min_union_blocking_factoAlternative 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

Angebot anfordern
Preisliste herunterladen
Expert Session
Support