Ansicht
Dokumentation

ABENITAB_KEY_MEMORY - ITAB KEY MEMORY

PERFORM Short Reference   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Zeilenbezogene Verwaltungskosten

Neben dem unter Speicherbedarf tiefer Datenobjekte aufgeführten grundsätzlichen Speicherbedarf, der für die Verwaltung interner Tabellen in Tabellenheadern entsteht, wird zusätzlicher Speicher für Verwaltung jeder einzelnen Zeile benötigt, die einen optimierten Zugriff auf einzelne Zeilen erlaubt. Diese interne Verwaltung einzelner Zeilen hat zwei Ausprägungen:

• Ein Tabellenindex verwaltet die logische Reihenfolge von Tabellenzeilen. Der zusätzliche Speicherbedarf liegt im Mittel bei 6 Byte pro Tabellenzeile. Wenn die logische Reihenfolge mit der physischen Reihenfolge im Tabellenkörper übereinstimmt, dann wird kein zusätzlicher Speicher für den Index benötigt.

• Eine Hash-Verwaltung dient dem Zugriff auf Tabellenzeilen durch das Verhashen der zugehörigen Schlüsselkomponenten. Der zusätzliche Speicherbedarf liegt im Mittel bei 18 Byte pro Tabellenzeile, solange nicht mit einer der Anweisungen DELETE oder SORT auf die Tabelle zugegriffen wird. Nach einem solchen Zugriff werden im Mittel 30 Byte pro Tabellenzeile benötigt.

Welche Verwaltung für eine Tabellenzeile ausgeführt wird hängt von der Tabellenart und den eventuellen sekundären Tabellenschlüsseln ab. Die Tabellenart bestimmt die grundlegende Verwaltung der Zeilen einer internen Tabelle (Tabellenindex bei Indextabellen, Hash-Verwaltung bei Hash-Tabellen). Jeder zusätzliche sekundäre Tabellenschlüssel führt eine zusätzliche Zeilenverwaltung ein (Tabellenindex bei sortierten Schlüsseln, Hash-Verwaltung bei Hash-Schlüsseln.

Indizes werden also in folgenden Fällen angelegt:

• Als primärer Tabellenindex einer Standardtabelle, um die durch Indexoperationen entstandene Reihenfolge zu verwalten. Die im Index vorliegende Ordnung hat aber keinerlei Bezug zum Inhalt der Tabellenzeilen. Der Index dient ausschließlich zur Optimierung von Indexzugriffen. Inhaltliche Suchen können nicht optimiert werden und führen immer zu einer linearen Suche über alle Tabellenzeilen.

• Als primärer Tabellenindex einer sortierten Tabelle oder als sekundärer Tabellenindex eines sortierten sekundären Tabellenschlüssels einer beliebigen Tabelle, um die Reihenfolge der Tabellenzeilen gemäß dem sortierten primären oder sekundären Tabellenschlüssels zu verwalten. Dabei wird die Reihenfolge der Tabellenzeilen durch die durch den sortierten Tabellenschlüssel definierte Sicht auf die Tabellenzeilen bestimmt. Dadurch ist auf den Zeilen der Tabelle eine Ordnung definiert, die zum optimierten Zugriff durch binäre Suche genutzt werden kann.

Hash-Verwaltungen werden in folgenden Fällen angelegt:

• Für den primären Tabellenschlüssel einer Hash-Tabelle oder für einen sekundären Hash-Schlüssel einer beliebigen Tabelle. Sie erlauben keinen Indexzugriff. Sie können einzig zum optimierten Zugriff mit vollständig spezifiziertem Tabellenschlüssel verwendet werden.

Daneben kann die Verwendung sekundärer Tabellenschlüssel weitere Speicherkosten verursachen.

• Eine interne Tabelle, die mindestens einen mehrdeutigen sortierten Sekundärschlüssel hat, benötigt zusätzlich 8 Byte pro Tabellenzeile an Grundkosten zur Verwaltung eventueller Duplikate. Diese zusätzlichen Grundkosten fallen nicht pro Tabellenschlüssel, sondern nur einmalig an.

• Weitere Speicherkosten entstehen, wenn ein Sekundärschlüssel nach einer Änderung des Inhalts der internen Tabelle aktualisiert werden muss. Diese bewegen sich in Größenordnungen von einigen Bytes pro Zeile und hängen auch stark von der Anzahl der Änderungen ab.

Beispiele

• Eine Standardtabelle mit einem sekundären Hash-Schlüssel, die ausschließlich mit APPEND gefüllt wurde, benötigt

• keinen zusätzlichen Speicherbedarf für den Primärindex, da logische und physische Reihenfolge übereinstimmen,

• 18 Byte pro Zeile für die Hash-Verwaltung des Sekundärschlüssels.

Nach einen Zugriff über DELETE oder SORT steigt der Speicherbedarf pro Zeile auf 6 Byte für den Primärindex und 30 Byte für die Hash-Verwaltung.

• Eine sortierte Tabelle mit einem sekundären Hash-Schlüssel und zwei nicht-eindeutigen sortierten Sekundärschlüsseln benötigt

• 6 Byte pro Zeile für den Primärindex,

• 18 bzw. 30 Byte pro Zeile für die Hash-Verwaltung des sekundären Hash-Schlüssels,

• 6 Byte pro Zeile und Schlüssel für die sortierten Sekundärschlüssel, ab dem Moment ab dem sie benutzt werden,

• 8 Byte pro Zeile weil es mindestens einen nicht-eindeutigen sortierten Sekundärschlüssel gibt.

BAL Application Log Documentation   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7616 Date: 20240523 Time: 162805     sap01-206 ( 114 ms )