Ansicht
Dokumentation

ABENOPEN_SQL_PERFORMANCE - OPEN SQL PERFORMANCE

General Material Data   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Performance-Hinweise zu einzelnen Open-SQL-Anweisungen

SELECT

Angabe der Ergebnismenge

1. Bei Verwendung der Zusätze SINGLE FOR UPDATE und DISTINCT wird die SAP-Pufferung umgangen.
   
   
2. Der Zusatz DISTINCT erfordert Sortierungen auf dem Datenbankbankserver und sollte deshalb nur angegeben werden, wenn mit Duplikaten gerechnet werden muss.
   
   
3. Bei Angabe von Aggregatfunktionen wird die SAP-Pufferung umgangen.
   
   
4. Da manche Datenbanksysteme die Anzahl der Zeilen einer Tabelle nicht in ihrem Katalog verwalten und deshalb aufwändig besorgen müssen, eignet sich die Funktion COUNT( * ) nicht gut, um zu prüfen, ob eine Tabelle überhaupt eine Zeile enthält. Dazu verwenden Sie am besten SELECT f ... FROM tab UP TO 1 ROWS für ein beliebiges Tabellenfeld f.
   
   
5. Falls nur bestimmte Spalten einer Datenbanktabelle selektiert werden sollen, empfiehlt es sich eine Liste von Feldern in der SELECT-Klausel anzugeben oder einen View zu verwenden.
   
   

Angabe des Zielbereichs

1. Ob Daten besser in eine interne Tabelle oder in einen Arbeitsbereich eingelesen werden sollen, hängt von der Art der weiteren Verarbeitung ab: Werden Daten in einem Programm nur einmal benötigt, so sollten sie mit einer SELECT-ENDSELECT-Schleife zeilenweise in einen Arbeitsbereich eingelesen werden. Das Einlesen in eine interne Tabelle benötigt mehr Speicherplatz, ohne diesen Nachteil durch eine wesentlich höhere Lesegeschwindigkeit auszugleichen. Werden Daten dagegen in einem Programm mehrfach benötigt, so sollten sie in eine interne Tabelle eingelesen werden. Der Nachteil des höheren Speicherbedarfs wird hier durch den Vorteil der einmaligen Selektion mehr als kompensiert.
   
   
2. Sollen Daten in eine interne Tabelle eingelesen werden, so ist es günstiger, sie auf ein Mal in die interne Tabelle einzulesen, als sie Zeile für Zeile in einen Arbeitsbereich und anschließend mit APPEND an die interne Tabelle anzufügen.
   
   
3. Die Varianten ... INTO CORRESPONDING FIELDS OF wa, ... INTO CORRESPONDING FIELDS OF TABLE itab und ... APPENDING CORRESPONDING FIELDS OF TABLE itab benötigen im Vergleich zu den entsprechenden Varianten ohne CORRESPONDING FIELDS eine etwas höhere - von der Größe der Lösungsmenge aber unabhängige - Laufzeit. Sie sollten deshalb möglichst vermieden werden.
   
   

Angabe der WHERE-Bedingung

1. Alle Bedingungen sollten in der WHERE-Klausel angegeben werden. Dadurch wird vermieden, dass Daten nutzlos über das Netzwerk transportiert und dann (z.B. mit CHECK) wieder aussortiert werden müssen.
   
2. Für häufig benutzte SELECT-Statements sollte ein Index angelegt werden. In der WHERE-Klausel sollten die Felder des Indexes durch das logische AND verknüpft mit Vergleichen auf Gleichheit angegeben werden. Alle Felder eines Indexes, die im Index hinter einem Feld stehen, für das in der WHERE-Klausel ein anderer Vergleich als EQ (=) angegeben ist, können nicht zur Suche im Index verwendet werden.
   
3. Das logische NOT in einer WHERE-Klausel kann nicht durch einen Index unterstützt werden. Beispielsweise ist WHERE fldate >= '20010228' besser als WHERE NOT fldate < '20010228'.
   
   
4. Der SAP-Puffer unterstützt nicht die Bedingung IS NULL. Deshalb verhält sich jeder SELECT-Befehl auf eine gepufferte Tabelle bzw. auf einen View mit Feldern aus gepufferten Tabellen, der ... WHERE f IS [NOT] NULL enthält, so, als wäre der Zusatz BYPASSING BUFFER in der FROM-Klausel angegeben.
   
   
5. Da bei der dynamischen Angabe einer Bedingung u.a. die Syntaxprüfung erst zur Laufzeit erfolgen kann, benötigt die Angabe einer logischen Bedingung zur Laufzeit etwas mehr Ausführungszeit als eine entsprechende Angabe im Programmtext.
   
6. Das Suchen nach Variablennamen in der Laufzeitumgebung ist aufwändig. Wird als Wert eine ABAP-Variable verwendet, so sollte die Definition dieser Variablen bei der dynamischen Angabe einer Bedingung nach Möglichkeit im aktuellen Kontext erfolgen.
   
   

Zeilen gruppieren

Werden Aggregate und Gruppen bereits vom Datenbanksystem und nicht erst vom Applikationsserver gebildet, kann dies erheblich zur Reduzierung der Datenmenge, die vom Datenbank- zum Applikationsserver transportiert werden muss, beitragen.

Zeilen sortieren

1. Im Gegensatz zu ... ORDER BY PRIMARY KEY ist ... ORDER BY f1 f2 ... nicht automatisch durch einen (sortierten) Index unterstützt. Ohne einen entsprechenden Index muss die Ergebnismenge aber zur Laufzeit sortiert werden. Auf Grund der SAP-Architektur sollte dies nicht auf dem Datenbankserver, sondern auf dem Applikationsserver geschehen. Falls es nicht sinnvoll ist, einen entsprechenden Index anzulegen, sollte die Ergebnismenge deshalb nicht mit ... ORDER BY f1 f2 ... auf dem Datenbankserver, sondern mit SORT auf dem Applikationsserver sortiert werden.
   
2. Bei größeren Datenmengen sollte die Variante ... ORDER BY f1 f2 ... nur angewendet werden, wenn die Reihenfolge der Datenbankfelder f1 f2 ... genau der Reihenfolge eines Indexes entspricht.
   
3. Im Gegensatz zu ... ORDER BY PRIMARY KEY umgeht ... ORDER BY f1 f2 ... die SAP-Tabellen-Pufferung.
   
   

INSERT, UPDATE, MODIFY, DELETE

Wenn mehrere Zeilen einer Datenbanktabelle geändert werden sollen, sind Mengenzugriffe prinzipiell performanter als Einzelzugriffe.

ABAP Short Reference   Addresses (Business Address Services)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7881 Date: 20240523 Time: 100522     sap01-206 ( 141 ms )