Ansicht
Dokumentation

ABENDELETE_ITAB_USING_KEY_ABEXA - DELETE ITAB USING KEY ABEXA

Vendor Master (General Section)   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Zeilen über WHERE löschen

Das Beispiel misst die Laufzeit der Anweisung DELETE ... WHERE mit verschiedenen Tabellenschlüsseln.

Quelltext

Ausführen

Beschreibung

Die Tabelle itab ist eine Hash-Tabelle mit einem eindeutigen Primärschlüssel und einem nicht-eindeutigen sekundären sortierten Schlüssel. Die Methode refresh_itab füllt die Tabelle mit 100.000 Zeilen, wobei die zweite Spalte Zufallszahlen zwischen 1 und 10 enthält.

Das Programm misst die Laufzeit der Anweisung DELETE itab, wobei hinter WHERE eine Bedingung auf die Spalte gesetzt wird, die den Sekundärschlüssel bestimmt.

• Bei der ersten DELETE-Anweisung unterdrücken wir aus Demonstrationszwecken mit dem Pragma ##PRIMKEY die Warnung von der Syntaxprüfung, dass mit dem Primärschlüssel auf die interne Tabelle zugegriffen wird, ohne dass dessen Komponenten versorgt werden. Bei diesem Zugriff muss die ganze interne Tabelle linear durchsucht werden.

• Bei der zweiten DELETE-Anweisung wird der Sekundärschlüssel angegeben. Da nach dem Füllen der internen Tabelle aber noch kein Zugriff über diesen Schlüssel erfolgt ist, muss der sekundäre Tabellenschlüssel erst aufgebaut werden (lazy update). Diese Zeit wird bei der DELETE-Anweisung mit gemessen und macht diese scheinbar wesentlich langsamer als die vorhergehende nicht-optimierte Anweisung.

• Nach dem erneuten Füllen der internen Tabelle wird der Sekundärschlüssel explizit mit der Methode FLUSH_ITAB_KEY der Klasse CL_ABAP_ITAB_UTILITIES aufgebaut. Die gemessene Zeit gibt im Wesentlichen die für die Erzeugung des Index benötigte Laufzeit an.

• Bei der dritten DELETE-Anweisung wird wieder der Sekundärschlüssel angegeben, wobei dieser durch den vorhergehenden Methodenaufruf jetzt aber bereits vorhanden ist. Die Laufzeit dieser DELETE-Anweisung ist wie erwartet viel schneller als die der beiden vorhergehenden. Die Summe dieser Laufzeit und der für den Indexaufbau benötigten ergeben die der zweiten DELETE-Anweisung.

• Bei der vierten DELETE-Anweisung wird der gleiche Löschvorgang auf einer sortierten internen Tabelle jtab ausgeführt, die den gleichen Zeilentyp und Inhalt wie die vorhergehende Tabelle itab hat, die aber deren Sekundärschlüssel als einzigen Schlüssel hat. Die Laufzeit liegt in der gleichen Größenordnung wie der Zugriff auf itab über den sekundären sortieren Schlüssel, ist aber kürzer, da für die interne Tabelle nur ein einziger Schlüssel verwaltet werden muss. Würde man für jtab einen sekundären Schlüssel, wie z.B. einen Hash-Schlüssel für die erste Spalte, deklarieren, wären die Laufzeiten der letzten beiden DELETE-Anweisungen in etwa gleich.

Das Beispiel zeigt, dass durch die Verwendung von sekundären Tabellenschlüsseln große Performance-Gewinne erzielt werden können, die das Kopieren auf Tabellen mit geeignetem Schlüssel ersparen. Es zeigt aber auch, dass für den Aufbau eines sekundären Index erhebliche Kosten anfallen können, die wegen des lazy update oft an unerwarteten Stellen auftreten. Sekundärschlüssel sind als eher für häufige lesende Zugriffe als für wenige ändernde Zugriffe auf große Tabellen geeignet.

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

Length: 4263 Date: 20240523 Time: 161500     sap01-206 ( 98 ms )