Ansicht
Dokumentation

ABENITAB_PERFO - ITAB PERFO

CL_GUI_FRONTEND_SERVICES - Frontend Services   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Performance-Hinweise

Tabellen-Sharing

Bei Zuweisungen zwischen gleichartigen internen Tabellen, deren Zeilentypen selbst keine Tabellentypen enthalten, werden aus Performancegründen nur die internen Verwaltungsfunktionen auf den Tabellenkörper übergeben. Das Tabellen-Sharing wird erst aufgehoben, wenn ändernd auf eine der beteiligten Tabellen zugegriffen wird. Dann findet der eigentliche Kopiervorgang statt

Initial allokierter Speicherbereich

Interne Tabellen sind dynamische Datenobjekte, deren Bereich im Speicher blockweise erweitert wird. Die Größe des ersten Blocks im Speicher kann bei der Deklaration einer internen Tabelle durch die Zusätze INITIAL SIZE und dem obsoleten OCCURS gesteuert werden. Wenn der erste Block nicht mehr ausreicht, werden weitere Blöcke nach einer internen Verdoppelungsstrategie angelegt, bis eine maximale Größe erreicht wird. Alle weiteren Blöcke werden dann mit einer konstanten Größe zwischen 8 und 16 KB angelegt.

Die Bestimmung der Größe des ersten Blocks kann in der Regel dem System überlassen werden (keine Angabe von INITIAL SIZE bzw. Angabe des Werts 0). In diesem Fall wird beim ersten Zufügen von Zeilen zu einer internen Tabelle eine geeignete Blockgröße gewählt.

Die Angabe eines konkreten Wertes größer als 0 hinter INITIAL SIZE ist nur dann sinnvoll, wenn man von vornherein genau weiß, wie viele Einträge in die Tabelle kommen sollen und man deshalb den ersten Block möglichst passend dimensionieren will. Dies kann insbesondere für interne Tabellen wichtig sein, die Komponenten anderer interner Tabellen sind, und nur wenige Zeilen (nicht mehr als etwa fünf) enthalten.

Um übergroße Speicheranforderungen zu vermeiden, werden Werte, welche Speicheranforderungen größer als die konstante Blockgröße ergeben, ignoriert.

Index-Administration

Bei einer Indextabelle stimmt die logische Reihenfolge der Tabelleneinträge in der Regel nicht mit der physikalischen Reihenfolge der Einträge im Hauptspeicher überein. In diesem Fall wird die logische Reihenfolge nicht mehr durch einen physikalischen, sondern durch einen logischen Index verwaltet. Für die sekundären Tabellenindizes, die der Verwaltung sekundärer sortierter Schlüssel dienen, gilt im Wesentlichen das Gleiche.

Durch den logischen Index entsteht zum Einen zusätzlicher Speicherbedarf und zum Anderen fallen beim Einfügen oder Löschen von Tabellenzeilen Indexpflegekosten an. Die Kosten steigen proportional mit der Anzahl der hinter der Einfüge- bzw. Löschposition verbleibenden Zeilen. Bei sehr großen internen Tabellen können dadurch beträchtliche Laufzeitkosten entstehen.

Der logische Index wird in dem Moment angelegt, in dem eine Zeile vor einer anderen Zeile eingefügt, die Reihenfolge der Tabellenzeilen geändert oder eine andere als die letzte Zeile des Tabellenindex gelöscht wird. Ein logischer Index wird nicht benötigt, solange eine interne Tabelle ausschließlich mit APPEND gefüllt wird und wenn ausschließlich ihre jeweils letzte(n) Zeile(n) mit DELETE gelöscht werden.

Hinweis

Da im Gegensatz zum Füllen einer Tabelle mit INSERT beim Anhängen von Zeilen mit APPEND keine Indexpflegekosten anfallen, ist der Aufbau einer Standardtabelle mit APPEND dem Füllen mit INSERT vorzuziehen. Dies ist möglich, wenn es auf die Ordnung der Einträge nicht ankommt oder die Einträge in der richtigen Reihenfolge angehängt werden können.

Blockweises Bearbeiten von Tabellenzeilen

Wenn ganze Zeilenbereiche einer Tabelle auf einmal bearbeitet werden können, sollte dies nicht zeilenweise, sondern mit Hilfe von Blockoperationen erfolgen. Blockoperationen sind mit den Zusätzen FROM und TO der Anweisungen INSERT, APPEND und DELETE möglich. Weiterhin sind beim Einlesen aus oder Modifizieren von Datenbanktabellen mit -Anweisungen Blockoperationen mit den Zusätzen FROM$|APPENDING$|TO TABLE günstiger als Einzelsatzoperationen.

Selektiver Datentransport

Wenn beim Lesen von Tabellenzeilen mit READ TABLE bzw. LOOP AT ein Arbeitsbereich verwendet wird oder Tabellenzeilen über MODIFY statt über direkten Zugriff geändert werden, kann der Zusatz TRANSPORTING verwendet werden, um unnötige Zuweisungen von Komponenten der Tabelle an den Arbeitsbereich zu vermeiden. Dies kann zu einem spürbaren Geschwindigkeitsgewinn führen, insbesondere wenn tabellenartige Komponenten von der Verarbeitung ausgenommen werden.

Verwendung von Sekundärschlüsseln

Die Verwendung von sekundären Tabellenschlüsseln sollte sorgfältig geplant werden und sparsam erfolgen. Der Nutzen, der sich aus dem zeitlichen Gewinn beim Zugriff auf einzelne Zeilen ergibt, darf nicht durch den erhöhten Speicher- und Zeitbedarf für die Verwaltung der Sekundärschlüssel aufgehoben werden. Sekundärschlüssel empfehlen sich in der Regel für interne Tabellen, die einmal gefüllt und während der Ausführung eines Programms nur noch selten geändert werden.

Beispiel

Das Programm DEMO_SECONDARY_KEYS demonstriert die Angabe eines sekundären Tabellenschlüssels und den daraus resultierenden Performance-Gewinn.

Tabellenzeilen löschen

Beim Löschen von Zeilen einer internen Tabelle fallen Verwaltungskosten für alle Tabellenschlüssel und Tabellenindizes an. Der Primärschlüssel und alle eindeutigen Sekundärschlüssel werden direkt aktualisiert, während nicht-eindeutige Sekundärschlüssel nur aktualisiert werden, wenn die zu löschende Zeile im bereits aktualisierten Teil eines zugehörigen Index enthalten ist (lazy update).

Insbesondere ist zu beachten, dass im Fall von Standardtabellen die Laufzeit der Anweisung DELETE auch bei der Angabe von Sekundärschlüsseln über WITH TABLE KEY oder USING KEY im Mittel immer linear von der Anzahl der Tabellenzeilen abhängt, da zum Aktualisieren des Primärindex eine lineare Suche durchgeführt werden muss, obwohl die zu löschende Zeile selbst schnell gefunden wird.

Das Löschen von Zeilen interner Tabellen mit DELETE gibt in aller Regel keinen Speicher der internen Tabelle frei. Um Speicher interner Tabellen freizugeben, müssen Anweisungen wie CLEAR oder FREE verwendet werden.

Freie Schlüsselangabe bei sortierten Tabellen und Hash-Tabellen

Bei Verwendung der READ-Anweisung mit einer freien Schlüsselangabe der Form WITH KEY ... wird die Suche in allen Fällen optimiert, in denen dies möglich ist, d.h.

• bei sortierten Tabellen, wenn durch die Schlüsselangabe irgendein Anfangsstück des Tabellenschlüssels oder der komplette Tabellenschlüssel

• bei Hash-Tabellen der komplette Tabellenschlüssel

Genügt ein Teil eines freien Schlüssels diesen Bedingungen, wird zunächst mit diesem Teilschlüssel ein Eintrag gesucht. Bei sortierten Tabellen geschieht dies mit Binärer Suche, d.h. mit logarithmischem Aufwand, bei Hash-Tabellen über den internen Hash-Algorithmus, d.h. mit konstantem Aufwand. Falls ein Eintrag gefunden wurde, wird überprüft, ob die restlichen Schlüsselbedingungen ebenfalls erfüllt sind. Dies bedeutet insbesondere, dass auch überspezifizierte Schlüsselangaben optimiert werden.

Hinweis

Siehe auch Optimierung der WHERE-Bedingung.

Sortierung

Für die textuelle Sortierung einer internen Tabelle gemäß der aktuellen Textumgebung kann es in folgenden Fällen performanter sein, die Anweisung CONVERT TEXT INTO SORTABLE CODE statt SORT AS TEXT zu verwenden:

• Eine interne Tabelle soll gemäß einem Locale sortiert und dann mit der Anweisung READ TABLE oder einem Tabellenausdruck binär durchsucht werden.

• Eine interne Tabelle muss mehrmals sortiert werden.

• Indizes für Datenbanktabellen sollen gemäß einem Locale aufgebaut werden.

CPI1466 during Backup   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 12189 Date: 20240523 Time: 165258     sap01-206 ( 205 ms )