OpenSQL: Profilparameter des SELECT FOR ALL ENTRIES-Befehls
Autor: Alexander Depold | 5. August 2015
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.
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
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?
