Ansicht
Dokumentation

ABENDDIC_DATABASE_TABLES_INDEX - DDIC DATABASE TABLES INDEX

General Data in Customer Master   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Indizes von Datenbanktabellen

Ein Index einer DDIC-Datenbanktabelle dient zur Unterstützung der schnelleren Selektion von Zeilen. Er besteht aus ausgewählten Feldern einer DDIC-Datenbanktabelle, von denen eine Kopie in sortierter Reihenfolge angelegt wird. Ein zusätzliches Feld enthält einen Zeiger auf die eigentlichen Tabellenzeilen. Die Sortierung ermöglicht einen schnellen Zugriff auf die Zeilen der Tabelle, z.B. über eine binäre Suche. Eine DDIC-Datenbanktabelle hat mindestens einen durch ihre Schlüsselfelder definierten Primärindex und kann optional einen oder mehrere Sekundärindizes haben.

Primärindex

Der Primärindex ist ein eindeutiger Index, der aus den Schlüsselfeldern des Primärschlüssels aufgebaut ist. Er ist in einem AS ABAP immer automatisch angelegt. Zu jeder Kombination der Felder des Indexes existiert höchstens ein Satz in der Tabelle. Wenn der Primärindex nicht zur Bestimmung der Ergebnismenge benutzt werden kann, weil z. B. kein Feld des Primärindexes selektiert wird, wird die Tabelle entweder vollständig durchsucht oder es wird versucht einen passenden Sekundärindex zu verwenden, falls vorhanden.

Sekundärindizes

Sekundärindizes können nicht in der und in der nicht definiert werden.

Zusätzlich zu dem durch den Primärschlüssel definierten Primärindex können zu einer DDIC-Datenbanktabelle eindeutige und nicht-eindeutige Sekundärindizes angelegt werden. Das Anlegen von Sekundärindizes führt bei Datenbankzugriffen, welche die Indizes der Datenbank auswerten, in aller Regel zu Performanceverbesserungen.

Die Sekundärindizes einer Datenbanktabelle bestehen aus einer Reihe von Tabellenfeldern und werden durch eine maximal dreistellige Indexkennung identifiziert, die aus Buchstaben oder Ziffern bestehen muss. Die Kennung 0 ist für den Primärindex reserviert. Tabellenfelder der eingebauten Datentypen STRING, RAWSTRING und GEOM_EWKB dürfen und solche vom Datentyp FLTP sollten keine Indexfelder sein.

Beim Anlegen der DDIC-Datenbanktabelle im Datenbanksystem werden auch die für diese bereits definierten Sekundärindizes angelegt. Weiterhin können im gleichen System nachträglich weitere Sekundärindizes hinzugefügt werden. Um in anderen Systemen modifikationsfrei weitere Sekundärindizes hinzuzufügen werden diese dort als sogenannte Extension-Indizes angelegt. Als Namensräume für nachträglich hinzugefügte Indizes wird empfohlen:

• Die Kennungen von Indizes, die von Kunden zu ausgelieferten Tabellen hinzugefügt werden, beginnen mit "Y" oder "Z".

• Die Kennungen von Indizes, die von Partnern zu ausgelieferten Tabellen hinzugefügt werden, beginnen mit "J". Die Namen der Indizes verschiedener Partner können in Folgesystemen kollidieren.

• Die Kennungen von Indizes, die zu eigenen Tabellen hinzugefügt werden, sind beliebig, dürfen aber nicht mit "Y", "Z" oder "J" beginnen.

Der Name eines Index auf der Datenbank ist in der Regel DBTAB~ID, wobei DBTAB der Name der DDIC-Datenbanktabelle und ID die dreistellige Kennung ist, wobei eventuell auch andere Namen vorkommen können oder Leerstellen mit Unterstrichen aufgefüllt werden.

Ein Sekundärindex muss im Gegensatz zum Primärindex nicht eindeutig sein. Bei einem eindeutigen Index kann es in der DDIC-Datenbanktabelle nicht mehrere Zeilen mit den gleichen Werten in den Indexfeldern geben. Der Versuch, eine solche Zeile einzufügen führt zu einem Abbruch der Verarbeitung in der Datenbank und in ABAP zu einer entsprechenden Ausnahme. Ein eindeutiger Index einer mandantenabhängigen Tabelle muss immer das Mandantenfeld enthalten.

Bei einem Datenbankzugriff überprüft der Optimizer des Datenbanksystems, ob ein geeigneter Index vorhanden ist, und verwendet diesen gegebenenfalls für den Zugriff. Da die Auswahl eines Index plattformabhängig ist, kann im ABAP Dictionary gesteuert werden, für welche Datenbanksysteme ein nicht-eindeutiger Sekundärindex vorgesehen ist und für welche nicht:

• Index auf allen Datenbanksystemen

Der Index soll auf jeder Datenbank angelegt werden

• Auf ausgewählten Datenbanksystemen

Die Datenbanksysteme können durch eine Auswahlliste oder eine Ausschlussliste mit jeweils bis zu vier Einträgen festgelegt werden.

• Kein Datenbankindex

Der Index soll auf keiner Datenbank angelegt werden. Diese Einstellung erlaubt es, bereits existierende Sekundärindizes von der Datenbank zu löschen.

Diese Einstellungen beeinflussen nicht die Auswertung des des Sekundärindex im Tabellenpuffer. Ein im ABAP Dictionary definierter Sekundärindex wird bei entsprechender Pufferungsart immer ausgewertet.

Ein eindeutiger Sekundärindex wird immer angelegt und darf nicht mehr von der Datenbank gelöscht werden. Mit der Funktion SQL-Trace des Werkzeugs Performance-Trace (Transaktion ST05) kann festgestellt werden, welcher Index vom Datenbanksystem für Zugriffe verwendet wird.

Wie gut ein Index die Datenselektion aus einer Tabelle unterstützt, hängt davon ab, wie weit die über den Index selektierbare Datenmenge bereits die endgültig zu selektierende Menge darstellt. Es sind nur solche Felder in einem Index sinnvoll, welche die Ergebnismenge einer Selektion signifikant einschränken. Wenn ein Index aus mehreren Feldern zusammengesetzt ist, kann er auch Verwendung finden, wenn nur einige dieser Felder in einer Selektionsbedingung angeben werden. Dabei spielt die Reihenfolge der Felder des Index eine wichtige Rolle für die Zugriffsgeschwindigkeit. An erster Stelle müssen die Felder stehen, die bei vielen Selektionen mit konstanten Werten belegt sind. Ein Index ist bei der Selektion nur bis zum ersten nicht in der Selektionsbedingung spezifizierten Feld von Nutzen, bzw. ein Indexfeld wird im Allgemeinen nur dann verwendet, wenn alle vor ihm liegenden Indexfelder in der Selektionsbedingung angegeben sind. Wie schnell auf ein Feld zugegriffen wird, hängt davon ab, ob ein Index als eindeutig oder nicht eindeutig definiert ist.

Das Anlegen von Sekundärindizes ist in folgenden Fällen lohnenswert:

• Wenn nach Feldern selektiert wird, die noch in keinem Index enthalten sind, und die Antwortzeiten sehr schlecht sind, sollte ein passender Sekundärindex angelegt werden.

• Das Feld oder die Felder eines Sekundärindizes sollten so selektiv sein, dass jedem Indexeintrag höchstens 5 Prozent der Gesamtanzahl der Tabelleneinträge entsprechen.

• Es finden hauptsächlich Lesezugriffe auf die DDIC-Datenbanktabelle statt. Bei ändernden Zugriffen muss nämlich auch jeder zusätzliche Index aktualisiert werden.

• Werden nur solche Felder ausgelesen, die auch im verwendeten Index vorhanden sind, muss nach dem Indexzugriff kein zweiter Zugriff auf die Daten erfolgen. Werden also nur sehr wenige Felder selektiert, lassen sich deutliche Effizienzgewinne erzielen, wenn diese Felder komplett in einen Index aufgenommen werden.

Sekundärindizes können das System auch belasten, da diese bei jeder Änderung des Tabelleninhalts angepasst werden müssen. Jeder zusätzliche Index verlangsamt das Einfügen von Zeilen in die Tabelle. Tabellen, in die häufig neue Zeilen geschrieben werden, sollten nur wenige Indizes haben. Zu viele Indizes können auch dazu führen, dass der Optimizer eines Datenbanksystem einen falschen Index auswählt. Um dies zu verhindern sollten die Indizes einer Tabelle deshalb möglichst disjunkt sein, d.h. möglichst wenige Felder gemeinsam haben.

Ein Index sollte sich nur aus wenigen Feldern zusammensetzen, im Allgemeinen nicht mehr als vier, weil bei jeder Änderungsoperation, die auf die Felder des Indexes ausgeführt wird, auch der Index aktualisiert werden muss. Felder, die für Indizes in Frage kommen, sind:

• Felder, die häufig selektiert werden und die eine hohe Selektivität haben. Die selektivsten Felder sollten an den Anfang des Indexes gelegt werden.

• Für schwach besetzte Felder, deren Feldwert für die meisten Sätze der Tabelle leer ist, soll kein Index angelegt werden.

• Bei mehreren Indizes pro DDIC-Datenbanktabelle sollten Überschneidungen vermieden werden.

Es sollten nicht mehr als fünf Indizes auf einer Tabelle angelegt werden, weil

• jeder Index zu den Aktualisierungskosten beiträgt.

• das Datenvolumen sich vergrößert.

• der Optimizer des Datenbanksystems zu viele Auswahlmöglichkeiten erhält und dadurch leichter Fehler macht.

Es können nur Bedingungen durch einen Index unterstützt werden, die den Suchwert positiv beschreiben, wie z. B. =, LIKE. Bedingungen, die beispielsweise mit <> angegeben sind, können nicht vom Vorhandensein eines Indexes profitieren. Der Optimizer hört in der Regel auf zu optimieren, wenn in der Bedingung ein OR auftritt, d. h. er verwertet die mit OR geprüften Felder nicht mehr bei der Auswahl und Anwendung des Indexes. Eine Ausnahme bilden OR-Verknüpfungen, die ganz außen stehen. Deshalb sollte eine Bedingung, die eine OR-Verknüpfung auf einem für die Indexwahl relevanten Feld besitzt, eventuell umformuliert werden.

Hinweise

• Der Null-Wert wird bei einigen Datenbanksystemen nicht in den Indizes berücksichtigt, was zur Folge haben kann, dass bei der Selektion nach Null-Werten kein Index verwendet werden kann.

• Falls unbedingt notwendig, können in mit dem Zusatz %_HINTS Datenbankhinweise angegeben werden, um den Optimizer des Datenbanksystems bei der Auswahl eines Sekundärindex zu beeinflussen.

Beispiel

In der folgenden SELECT-Anweisung hört der Optimizer bei OR auf zu optimieren.

SELECT * FROM spfli
         WHERE carrid = 'LH' AND
              ( CITYFROM = 'FRANKFURT' OR  cityfrom = 'NEW YORK' ).

Nach einer Ersetzung durch die gleichwertige folgende Anweisung kann die gesamte Bedingung bezüglich vorhandener Indizes optimiert werden.

SELECT *
       FROM spfli
       WHERE ( carrid = 'LH' AND cityfrom = 'FRANKFURT' ) OR
             ( carrid = 'LH' AND cityfrom = 'NEW YORK' ).

Volltextindex

Die SAP-HANA-Datenbank unterstützt einen Volltextindex als sekundären Tabellenindex. Ein Volltextindex wird auf der Datenbank als zusätzlich unsichtbare Spalte angelegt. Der Inhalt der Spalte, für die ein Volltextindex angelegt wird, wird geeignet aufbereitet in dieser zusätzlichen Spalte abgelegt und wird bei entsprechenden Zugriffen ausgewertet.

Es gelten folgende Bedingungen:

• Ein Volltextindex kann nur für die SAP-HANA-Datenbank und für Tabellen der Speicherungsart Column Store angelegt werden.

• Ein Volltextindex kann nur für genau eine Spalte einer DDIC-Datenbanktabelle angelegt werden, deren eingebauter Datentyp CHAR, SSTRING, STRING oder RAWSTRING ist.

• Die DDIC-Datenbanktabelle muss eine Spalte für die Textsprache haben.

Ein Volltextindex ist immer nicht-eindeutig. Zugriffe, welche den Volltextindex ausnutzen beruhen auf dem SQL-Sprachelement WHERE CONTAINS .... Dieses wird derzeit noch nicht von unterstützt. Stattdessen muss Native SQL oder AMDP verwendet werden.

Hinweise

• Weitere Informationen zum Volltextindex finden Sie im SAP HANA Developer Guide.

• In SAP-HANA-Cloud-Datenbanken sind keine Volltextindizes möglich.

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

Length: 15688 Date: 20240523 Time: 173205     sap01-206 ( 261 ms )