Datenkompression unter Oracle (Teil II):

Komprimierung von Index Organized Tables

Indexorganisierte Tabellen stehen seit der Oracle Version 8 zur Verfügung. Auch diese Tabellen können komprimiert werden. Jedoch kann bei den indexorganisierten Tabellen das im Teil I dieser Reihe vorgestellte Verfahren der DATA SEGMENT COMPRESSION nicht verwendet werden. Dieser Artikel gibt einen Überblick über den Einsatz der indexorganisierten Tabellen und darüber, wie sie durch KEY COMPRESSION dennoch komprimiert werden können.

In Oracle Umgebungen werden überwiegend normale Tabellen (ORGANIZATION HEAP) mit Indizes zur Zugriffsoptimierung verwendet. Aus Gründen der Speicherkapazitäten und Zugriffszeiten kann aber auch der Einsatz von indexorganisierten Tabellen (IOT) in normaler bzw. komprimierter Form in Betracht gezogen werden. Dies ist nichts völlig neues, denn schon mit Oracle Version 8 wurden Indizes, IOT und KEY COMPRESSION eingeführt.

Um einen Überblick über den Einsatz der indexorganisierten Tabellen zu bekommen, stellen wir zunächst den Aufbau und die Konfigurationsmöglichkeiten einer IOT vor.

Weiterhin erläutern wir die Kompression unter Verwendung der Option COMPRESS. Anschließend vermitteln einige Beispiele aus einem aktuellen Projekt einen ersten Eindruck von der möglichen, zu realisierenden Platzersparnis und zeigen die Auswirkungen auf die Performance auf.

Was unterscheidet eine IOT von einer normalen Tabelle?

In Abbildung 1 sind die wesentlichen Unterschiede zwischen einer normalen Tabelle mit Index - das kann z. B. der PRIMARY KEY sein - und einer IOT dargestellt. Die normale Tabelle besteht zunächst einmal aus dem Datensegment, in dem die Datensätze normalerweise in unsortierter Reihenfolge vorliegen.

Abb. 1: Vergleich des Aufbaus einer normalen Tabelle mit Index und dem einer IOT.

Im dazugehörigen Index-Segment liegen die Index-Blöcke. Auf der untersten Ebene enthalten die Leaf-Blöcke zu allen Datensätzen je einen Index-Eintrag zusammen mit der ROWID als Zeiger auf den entsprechenden Datensatz (in Abbildung 1 mit „L ROWID“ gekennzeichnet).

In einer IOT gibt es kein Datensegment. Der verwendete Platz liegt also ausschließlich in Form eines Indizes vor. Im Unterschied zu einem Index gibt es in den Leaf-Blöcken jedoch keine Zeiger, sondern dort werden die Datensätze selbst gespeichert und zwar sortiert nach den Kriterien des PRIMARY KEY.

Eine IOT bietet sich immer dann an, wenn die Spalten des PRIMARY KEY einen wesentlichen Anteil am gesamten Datensatz ausmachen. Dann ist in vielen Fällen schon alleine durch die Verwendung einer IOT eine Platz­ersparnis gegenüber der Verwendung einer normalen Tabelle mit Index zu erwarten.

Wie wird eine IOT angelegt?

Das Anlegen einer IOT unterscheidet sich in zwei Punkten von einer normalen Tabelle.

1. Die Option ORGANIZATION INDEX muss angegeben werden.
2. Ein PRIMARY KEY ist zwingend notwendig, da er das Ordnungskriterium für die Datensätze ist.

Der PRIMARY KEY einer IOT sollte aus Gründen der Übersichtlichkeit, wie in Abbildung 2 dargestellt, einen Namen erhalten, der die Zu­gehörigkeit zu der entsprechenden Tabelle kennzeichnet.

-- Anlegen einer IOT
CREATE TABLE io_tab
  ( Stadt         VARCHAR2(50),
    Strasse       VARCHAR2(100),
    Hausnr        VARCHAR2(10),
    Eigentuemer   VARCHAR2(50),
    CONSTRAINT PK_IO_TAB PRIMARY KEY( Stadt, Strasse, Hausnr )
  )
ORGANIZATION INDEX
;

Wie arbeitet die KEY COMPRESSION?

Die KEY COMPRESSION ist das Kompressionsverfahren für Indizes. Sie kann somit auch bei indexorganisierten Tabellen eingesetzt wer­den und findet ausschließlich in den Leaf-Blöcken statt. Die Arbeitsweise soll am Beispiel eines zusammengesetzten Indizes, der hier der PRIMARY KEY einer IOT ist, näher beleuchtet werden (siehe Abbildung 3).

Abb. 3: Prinzip der Speicherung von Daten in einer IOT links ohne und rechts mit KEY COMPRESSION.

In der normalen Form, wie auf der linken Seite dargestellt, werden die vollständigen Datensätze gespeichert. Bei Verwendung der KEY COMPRESSION werden die Spalten des Indizes (in Abbildung 3 grün dargestellt) aufgeteilt in PREFIX und SUFFIX.

Zum PREFIX zählen im dargestellten Beispiel die ersten beiden Spalten. Das sind die Teile des Indizes, die nicht eindeutig sind. Das SUFFIX bilden die restlichen Spalten des Indizes bzw. im Fall der IOT alle restlichen Spalten.

In der komprimierten Form, dargestellt auf der rechten Seite, werden PREFIX und SUFFIX getrennt behandelt. In einem Block werden die SUFFIX-Einträge zu allen Datensätzen, aber nur alle unterschiedlichen PREFIX-Einträge gespeichert. Daraus ergibt sich die Platzersparnis. In dem Beispiel sind also die 1. und 6. Zeile von unten die PREFIX-Einträge und die restlichen sind SUFFIX-Einträge. In komprimierter Form werden somit ca. 30 Prozent des Speicherplatzes eingespart.

Folgende Eigenschaften der Verwendung einer IOT mit KEY COMPRESSION sind identisch mit der DATA SEGMENT COMPRESSION bei normalen Tabellen:

• In einem Leaf-Block einer IOT steckt die vollständige Information über alle in diesem Block enthaltenen Datensätze. Für einen Zugriff auf die Daten sind keine weiteren Informationen notwendig.
• Für den Anwender ändert sich beim Zugriff auf die Daten nichts. Die Kompression ist vollständig unsichtbar.
• In komprimierter Form enthalten die Blöcke mehr Datensätze. Dadurch werden insgesamt weniger Blöcke benötigt und die I/O-Last sinkt.
• Die Daten werden in komprimierter Form im Database Buffer gehalten. Es können also mehr Datensätze im zur Verfügung stehenden Puffer gehalten werden.

Bei der KEY COMPRESSION gibt es jedoch nicht die Einschränkung auf Blockoperationen wie bei der DATA SEGMENT COMPRESSION. Sie wird also bei jeder einzelnen Einfügeoperation angewendet.

Wie wird die KEY COMPRESSION eingerichtet?

Um eine komprimierte IOT zu erstellen, wird beim Anlegen die Option COMPRESS angegeben (siehe Abbildung 4). Zusätzlich kann die Anzahl der PREFIX-Spalten (im Beispiel "2") mitgegeben werden. Die Standardeinstellung für diesen Parameter ist: Anzahl der PRIMARY KEY Spalten – 1.

-- Anlegen einer komprimierten IOT
CREATE TABLE io_tab_co
  ( Stadt         VARCHAR2(50),
   Strasse       VARCHAR2(100),
   Hausnr        VARCHAR2(10),
   Eigentuemer   VARCHAR2(50),
   CONSTRAINT PK_IO_TAB PRIMARY KEY( Stadt, Strasse, Hausnr )
  )
ORGANIZATION INDEX
COMPRESS 2
;  

Die Eigenschaft COMPRESS ist bei einer IOT im Gegensatz zu einer normalen Tabelle direkt mit der physikalischen Organisation der Daten verknüpft. Daher ist eine Umschaltung der Eigenschaft mit dem Befehl "ALTER TABLE ... COMPRESS;" nicht möglich. Die Umwandlung einer bestehenden IOT erfolgt mit dem Befehl "ALTER TABLE ... MOVE;" (siehe Abbildung 5).

-- Umwandeln einer bestehenden IOT
-- normal      -> komprimiert
ALTER TABLE tab_name MOVE COMPRESS 2;
	
-- komprimiert -> normal
ALTER TABLE tab_name MOVE NOCOMPRESS;

Bei der Ausführung wird eine neue IOT mit der angegebenen Eigenschaft COMPRESS bzw. NOCOMPRESS angelegt. Danach erfolgt das Einfügen der Daten, das Löschen der alten IOT und das Umbenennen der neuen IOT.

Was bringt die KEY COMPRESSION?

Die Auswirkungen der KEY COMPRESSION bei einer IOT hängen natürlich stark von der jeweiligen Tabelle ab. Allerdings kann man im Allgemeinen schon sagen, dass sich bei einem zusammengesetzten PRIMARY KEY der Einsatz einer Kompression wahrscheinlich lohnen wird.

Im Einzelfall kann man vorab mit den in Abbildung 6 aufgeführten Befehlen ermitteln, wie groß die Platzersparnis in % (OPT_CMPR_PCTSAVE) sein wird und welches der optimale Parameter (OPT_CMPR_COUNT) für die Kompression wäre.

ANALYZE INDEX pk_iot_no_comp VALIDATE STRUCTURE;
	
SELECT name
      opt_cmpr_count,
      opt_cmpr_pctsave,
  FROM index_stats;
	
NAME            OPT_CMPR_COUNT  OPT_CMPR_PCTSAVE       
--------------  --------------  ------------------ 
PK_IOT_NO_COMP  2               59

Die ermittelten Werte für die Platzersparnis sind in der Regel sehr zuverlässig. Eine Ausnahme ist die Version 9.2.0.4: Durch einen Fehler werden für die Platzersparnis bei Tabellen mit mehr als ca. 500.000 Zeilen unsinnige Werte angezeigt. Hier kann man sich nur mit einer Teilkopie behelfen, die eine geringere Anzahl beinhaltet.

Beispiel aus einem aktuellen Kundenprojekt

Abbildung 7 zeigt einige Analyseergebnisse aus einem aktuellen Projekt. Die Analyse zeigt, dass sich die im Beispiel verwendete Tabelle gut für eine KEY COMPRESSION eignet. Die ersten Spalten des zusammengesetzten PRIMARY KEY sind nicht eindeutig und machen über 50 Prozent der Zeilenlänge aus.

Welche Auswirkungen hat die Kompression der Beispieltabelle?

Das Einfügen von Daten in eine komprimierte IOT unterscheidet sich nur wenig von den Vorgängen ohne Kompression. Es bringt keine wesentliche, zusätzliche CPU-Last mit sich. Beim Einfügen von Massendaten kann durch die Platzersparnis durchaus eine Verkürzung der Zeiten erzielt werden.

Für typische Abfragen sind in der Tabelle Ausführungszeiten für folgende Fälle angegeben:

1. für den Fall, dass die Daten vollständig von der Platte geladen werden müssen
2. für den Fall, dass sich die Daten schon im Puffer befinden.

Bei den ersten Zugriffen spielt das geringere Datenvolumen durch die Kompression die entscheidende Rolle. Wenn die Daten schon im Puffer liegen, sind die Unterschiede deutlich geringer.

Kleiner Knigge zum Umgang mit indexorganisierten Tabellen

Bei der Verwendung einer IOT sollte man immer im Hinterkopf behalten, dass es sich bei diesem Objekt unabhängig von der Verwendung der Kompression um einen Index handelt. Im Folgenden sind einige Punkte zusammengetragen, die im Umgang mit indexorganisierten Tabellen zu beachten sind:

• Informationen über die physikalischen Eigenschaften einer IOT (Größe, Partitionen usw.) findet man im Data Dictionary über den Namen des PRIMARY KEY. Daher ist es sinnvoll einen aussagekräftigen Namen zu vergeben.
• Die Änderung der physikalischen Eigenschaften einer IOT erfolgt immer über die Tabelle. Ein REBUILD des PRIMARY KEY ist nicht möglich. Aber mit dem Befehl „ALTER TABLE ... MOVE;“, der auch mit der Option ONLINE ausgeführt werden kann, wird die Tabelle und damit auch der PRIMARY KEY neu aufgebaut.
• Beim Einfügen von Massendaten sollte man auf die richtige Sortierung der Daten achten. In sortierter Form (NLS_SORT = BINARY) werden alle Blöcke praktisch vollständig gefüllt. Bei nicht sortierten Daten erhält man sehr viele, nur halbgefüllte Blöcke.
• Beim nachträglichen Einfügen von einzelnen Datensätzen in eine optimal organisierte IOT entstehen halbgefüllte Blöcke. Wie bei einem Index führt das mit der Zeit zu einer schlechten Speicherplatzausnutzung.

Fazit

Die KEY COMPRESSION ist gegenüber der DATA SEGMENT COMPRESSION wesentlich einfacher zu handhaben. Ob man sie bei einer indexorganisierten Tabelle einsetzt, hängt eigentlich ausschließlich von dem Platzgewinn ab, den man durch eine Kompression erzielen kann. Über den Platzgewinn kann man sich vorab durch eine Analyse der Daten informieren. Die Verwendung einer IOT mit Kompression unterscheidet sich praktisch nicht von der Verwendung einer IOT ohne Kompression.

Dr. Klaus Uebelgünn (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen