Datenkompression unter Oracle (Teil I)

Mit der Oracle 9i R2 Enterprise-Version wurde die Möglichkeit der Tabellenkompression, genauer DATA SEGMENT COMPRESSION, eingeführt. Dieser Artikel gibt einen Überblick zum Einsatz dieser Option.

Data-Warehouse-Umgebungen bestehen sehr häufig aus wenigen großen Tabellen, die teilweise redundante Informationen enthalten. Mit Blick auf Speicherkapazitäten und Zugriffszeiten kommt der Wunsch auf, die Daten in komprimierter Form abzulegen.

Mit der Oracle 9i R2 Enterprise-Version wurde die DATA SEGMENT COMPRESSION eingeführt. Um einen Überblick über den Einsatz dieser Option zu bekommen, möchten wir zunächst die Arbeitsweise, die Konfigurationsmöglichkeiten und die Verwendung darstellen.

Anschließend geben einige Beispiele aus einem aktuellen Projekt einen ersten Eindruck zu der möglichen, zu realisierenden Platzersparnis und zeigen die Auswirkungen auf die Performance auf. Eine weitere Möglichkeit zur Komprimierung von Daten ist die KEY COMPRESSION. Sie kann bei Indizes bzw. indexorganisierten Tabellen (IOT) verwendet werden. Dieses Feature werden wir in diesem Artikel jedoch nicht behandeln.

Wie wird komprimiert?

Die Datenkompression erfolgt auf Blockebene. Beim Einfügen in die Tabelle wird nach mehrfach auftretenden Datenwerten innerhalb eines Blocks gesucht. Für diese wird in jedem Block ein eigener Bereich reserviert. In diesem Bereich liegt die so genannte Symbol-Tabelle. Mehrfach auftretende Datenwerte werden ausschließlich in der Symboltabelle gespeichert.

Im restlichen Platz innerhalb des Blocks werden die eigentlichen Datensätze gespeichert. Diese enthalten für die komprimierten Datenwerte Zeiger auf die Symboltabelle.

Die Platzersparnis ergibt sich aus der Verwendung der Zeiger, die weniger Speicherplatz als die Datenwerte erfordern. Abbildung 1 zeigt das Prinzip der Datenspeicherung innerhalb eines Blocks einer normalen beziehungsweise einer komprimierten Tabelle.

Die dargestellten Datensätze würden in komprimierter Form 291 Byte und unkomprimiert 379 Byte belegen. In einem Block einer komprimierten Tabelle existieren komprimierte und unveränderte Datenwerte und Datensätze nebeneinander.

Die wesentlichen Eigenschaften dieser Kompression auf Blockebene sind Folgende:

1. Ein Datenblock enthält die vollständige Information über alle Datensätze innerhalb des Blocks. Für einen Zugriff auf die Daten sind keine weiteren Informationen notwendig.
2. Für den Anwender ändert sich beim Zugriff auf die Daten nichts. Die Kompression ist vollständig unsichtbar.
3. In komprimierter Form enthalten die Blöcke mehr Datensätze. Dadurch sinkt die I/O-Last.
4. 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.

Abb. 1: Prinzip der Speicherung von Daten in einer normalen und in einer komprimierten Tabelle. (vergrößern)

Wie wird die Datenkompression eingerichtet?

-- Anlegen einer komprimierten Tabelle
CREATE TABLE podium_le_tour_comp
  ( jahr      DATE,
    name      VARCHAR2(100),
    platz     Number,
    team      VARCHAR2(100) )
COMPRESS;

Um eine komprimierte Tabelle zu erstellen, wird beim Anlegen die Option COMPRESS angegeben (siehe Abbildung 2). Damit wird die Eigenschaft COMPRESSION der Tabelle auf „ENABLED„ gesetzt. Beim Einfügen von Daten werden dann zunächst die Möglichkeiten einer Komprimierung getestet.

Sehr wichtig ist auch, dass der Speicherparameter PCTFREE automatisch den Wert "0" erhält. Es wird also kein Puffer für eventuelle Updates gelassen. Dies ist jedoch auch nicht notwendig, da Updates dem Konzept der Komprimierung widersprechen.

Nachträgliche Änderungen der Daten einer komprimierten Tabelle führen zunächst zu einer Dekomprimierung. Nach der Änderung werden die Datensätze dann in unkomprimierter Form wieder eingefügt. Dadurch geht die angestrebte Platzersparnis also verloren.

-- Umwandeln einer bestehenden Tabelle
-- normal      -> komprimiert
ALTER TABLE tab_name MOVE COMPRESS;

-- komprimiert -> normal
ALTER TABLE tab_name MOVE NOCOMPRESS;

Weitere Möglichkeiten der Verwendung der Eigenschaft COMPRESSION sind:

• die Definition auf TABLESPACE-Ebene. Dann erben alle Tabellen diese Eigenschaft.
• die Definition für eine partitionierte Tabelle. Die Kompression kann entweder für die gesamte Tabelle oder für einzelne Partitionen eingerichtet werden.
• die Definition für eine MATERIALIZED VIEW. Diese kann direkt beim Anlegen mit "CREATE MATERIALIZED VIEW ...COMPRESS AS ...;" erfolgen. Mit "ALTER MATERIALIZED VIEW ... COMPRESS;" werden die Daten beim nächsten Aktualisieren in komprimierter Form abgelegt.

Wann wird die Datenkompression verwendet?

Die Datenkompression erfolgt ausschließlich beim Einfügen von Daten in die Tabelle. Das beschriebene Verfahren wird jedoch nur angewandt, wenn mehrere Datensätze in einer Aktion eingefügt werden. Bei Datenmengen, die kleiner als ein Block sind, wird keine Kompression durchgeführt. Zum Einfügen muss eine der folgenden Blockoperationen (BULK LOAD oder BULK INSERT) verwendet werden:

• Verwendung des SQL*Loader mit der Option "direct = true"
• Verwendung des Befehls "CREATE TABLE . . . AS SELECT . . . "
• Einfügen von Daten mit "INSERT /*+ APPEND */ . . . "
• Einfügen von Daten mit "INSERT /*+ PARALLEL( tab_name, n) */ . . . "

Wird keine der hier aufgeführten Möglichkeiten benutzt, werden die Datensätze in normaler Form, also ohne Kompression, eingefügt.

Bei der Umwandlung einer bestehenden Tabelle in eine komprimierte mit "ALTER TABLE ... COMPRESS;" wird nur die Eigenschaft umgeschaltet. Die bestehenden Datensätze werden nicht geändert. Dies erfolgt erst mit den in Abbildung 3 aufgeführten Befehlen mit dem Zusatz "MOVE".

Bei der Ausführung wird eine neue Tabelle mit der Eigenschaft COMPRESSION angelegt. Danach erfolgt das Einfügen der Daten in komprimierter Form, das Löschen der alten Tabelle und das Umbenennen der neuen Tabelle.

Was bringt die Datenkompression?

Die Auswirkungen der Datenkompression hängen stark von der jeweiligen Tabelle ab. Wir wollen hier beispielhaft mit den Daten aus DBA_OBJECTS allgemeine Trends aufzeigen.

In Abbildung 4 sind die Unterschiede beim Anlegen mit "CREATE TABLE ... AS SELECT * FROM dba_objects;" dargestellt. Die komprimierte Tabelle belegt nur noch 43 Prozent des ursprünglichen Platzes. Daraus ergeben sich weniger Schreiboperationen bei den Daten und beim Redo-LOG. Auf der anderen Seite sind die CPU-Belastung und der PGA-Speicherverbrauch deutlich angestiegen.

Wie sieht das nun beim Zugriff auf die Daten aus? Diese Frage ist quantitativ noch schwieriger zu beantworten, da sie entscheidend durch die jeweilige Abfrage beeinflusst wird. Bei einem FULL TABLE SCAN spielt das geringere Datenvolumen eine entscheidende Rolle. Bei wiederholten Zugriffen auf die Daten einer komprimierten Tabelle wird es die Tatsache sein, dass mehr Datensätze im Puffer gehalten werden können. Es ist auf jeden Fall mit einer höheren CPU-Belastung zu rechnen, da die Daten für die Verwendung entkomprimiert werden müssen.

Die Auswirkungen am Beispiel

Die möglichen Auswirkungen der Kompression lassen sich am Besten an einem praktischen Beispiel aus einem aktuellen Projekt verdeutlichen. In Abbildung 5 sind dazu Informationen zu einer Tabelle dargestellt, die sich gut für eine Kompression eignet.

Die komprimierte Tabelle belegt nur noch ca. 22 Prozent des ursprünglichen Platzes. Für typische Abfragen sind dann Ausführungszeiten angegeben und zwar

1. für den Fall, dass die Daten vollständig von der Platte geladen werden müssen und
2. für den Fall, dass sich die Daten schon im Puffer befinden. In diesem Fall sind die beiden Ziele „Platzersparnis„ und „Performance-Gewinn„ erfüllt.

Kann ich Datenkompression einsetzen?

Jetzt kommen wir zu der entscheidenden Frage: Wann eignet sich eine Tabelle für den Einsatz der Datenkompression?

Absolut nicht geeignet sind Tabellen, wenn die Daten mit Einzeloperationen eingefügt und/oder durch UPDATEs verändert werden. Dann bewirkt die Kompression im günstigsten Fall nichts. Bei regelmäßigen UPDATEs wirkt sie sich sogar negativ auf Platzbedarf und Performance aus.

Sehr gut geeignet sind Tabellen, die folgende Bedingungen erfüllen:

• Die Tabelle enthält redundante Informationen.
• Die Daten werden mit Blockoperationen eingefügt.
• Die Daten werden einmal geschrieben und danach nur gelesen.

Fazit

Die Datenkompression ist keine Allzweckwaffe. Sie führt jedoch, wie das Beispiel aus der Praxis gezeigt hat, in Einzelfällen zu enormer Platzersparnis und bringt auch einen Performancegewinn. Vor der Anwendung der Kompression für eine Tabelle ist jedoch eine genaue Analyse der Auswirkungen auf das Einfügen der Daten und die Ausführungszeiten von typischen Abfragen notwendig.

Seitenanfang

Seite drucken

Seite weiterempfehlen