Oracle Compression - Weniger ist mehr

In einigen Projekten bin ich in den letzten Monaten immer wieder von Kunden mit Fragen zum Thema Komprimierung angesprochen worden. Es herrscht offensichtlich eine große Unsicherheit, welche Komponenten zusätzlich lizenziert werden müssen und welche in der SE2 oder EE enthalten sind. Außerdem ist für viele Kunden interessant, ob die Verwendung der Komprimierung merkbare Einsparungen im Hinblick auf Performance und Plattenplatz mit sich bringt. In diesem Artikel geben wir eine Lizenzübersicht, stellen die Möglichkeiten kurz dar und berichten von Lasttests.

Lizenzsituation

Wer die SE2 lizenziert hat, kann Backups in Oracle 12c unter bestimmten Umständen komprimieren. Wer die EE hat, kann zusätzlich Tabellen beim Laden, sowie Indizes und IOTs komprimieren. Für alle anderen Methoden muss die Advanced-Compression-Option zusätzlich zur EE lizenziert werden (siehe Abbildung 1).

Überblick

Mit der Datenbankversion 9i (Release 2) hat Oracle die Komprimierung von Tabellen für Bulk Loads eingeführt. Hierdurch kann der Speicherbedarf für Datensätze bei einem DIRECT LOAD oder bei dem Befehl CREATE TABLE ... AS SELECT ... reduziert werden. 

Diese Art der Datenkomprimierung eignet sich in hervorragender Weise für Data-Warehouse-Umgebungen, in denen der Großteil der Daten durch Batchjobs in die Datenbank gebracht wird. In der Datenbankversion 11g wurde das neue Feature OLTP Table Compression eingeführt. Die Möglichkeit, Daten zu komprimieren wurde hierbei auf alle DML-Operationen, wie INSERT, UPDATE und DELETE, ausgeweitet. Hierbei handelt es sich nicht um eine schlichte Erweiterung, sondern der verwendete Algorithmus ist komplett überarbeitet worden, um den Overhead bei Schreiboperationen zu reduzieren. Dadurch hat sich der Einsatzbereich auf die OLTP-Tabellen erweitert. IOTs können seit Oracle 9i, Indizes bereits seit Oracle 8i komprimiert werden.

Basic Table Compression – Compression For Direct Load Operation

Mit der Oracle 9iR2 wurde die „Compression for Direct Load Operations" eingeführt. 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 Symboltabelle.

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. Um eine komprimierte Tabelle zu erstellen, wird beim Anlegen die Option COMPRESS angegeben.

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.

Nur bei Verwendung einer der folgenden Blockoperationen (BULK LOAD oder BULK INSERT) erfolgt eine Komprimierung:

• SQL*Loader mit der Option "direct = true"
• CREATE TABLE . . . AS SELECT . . . "
• INSERT /*+ APPEND */ ... 
  INSERT /*+ PARALLEL( tab_name, n) */ ...

Die Komprimierungsrate ist stark von der Weise abhängig, in der die Daten geladen werden. Es sollte dafür gesorgt werden, dass die Daten in sortierter Reihenfolge in die Tabelle gelangen, um die Blöcke direkt optimal zu befüllen.

Table Compression – Compression For All Operations

Die Kompressionsmethode steht ab Oracle 11g zur Verfügung (bei Lizenzierung der Advanced-Compression-Option).

Die grundlegende Methode der Komprimierung wurde hierbei nicht verändert. Die Einsparungsquote ist somit auch hier stark von der Gleichartigkeit der Datensätze innerhalb eines Datenblocks abhängig.

Um den durch die Komprimierung der Daten entstehenden Overhead zu reduzieren, werden die Datensätze nicht einzeln, sondern blockweise in einer Art Batch-Job komprimiert.

Ein leerer Datenbankblock wird zunächst mit unkomprimierten Daten gefüllt, bis die Freispeichergrenze PCTFREE erreicht wird. Wird diese Grenze überschritten, wird der gesamte Inhalt des Datenbankblocks nach der oben genannten Kompressionsmethode komprimiert. Aus einem unkomprimierten Block wird in diesem Schritt ein komprimierter Block. Dieser Datenbankblock steht weiterhin für die Aufnahme von Datensätzen durch INSERT-Statements bereit. Durch die weitere Aufnahme von Datensätzen wird aus dem unkomprimierten Block ein teilweise komprimierter Block. Durch erneutes Erreichen der Freispeichergrenze wird der teilweise komprimierte Datenbankblock nochmals komprimiert. Es entsteht wiederum ein vollständig komprimierter Datenblock. Diese Prozedur wird fortgesetzt, bis der Block gefüllt ist. 

Aufgrund dieser Vorgehensweise lösen nur wenige SQL-Statements die eigentliche Komprimierung der Daten aus, wodurch die Performance nur minimal beeinträchtigt wird.

Index Compression

Doppelte Indexwerte werden bei einem komprimierten Index nur einmalig gespeichert. Dadurch kann der Index- Baum kleiner werden, die Anzahl der Leaf-Blöcke kann minimiert werden. Natürlich ist das Ziel der Komprimierung auch eine Minimierung der Plattenzugriffe. Eine Index-Komprimierung kann sehr sinnvoll sein, wenn die indizierte Spalte wenig unterschiedliche Werte enthält oder wenn der Index aus mehreren Spalten zusammengesetzt ist.

Mit Oracle 12c ist eine weitere Methode hinzugekommen: Die Advanced Index Compression. Dieses Verfahren darf nur bei Lizenzierung der Advanced-Compression-Option genutzt werden und ist für sehr ungleichmäßig verteilte Indizes gedacht. Die Erfahrungen aus der Praxis in 12.1 sind bisher nicht vielversprechend.

LOB Compression

Mit Oracle 12c sind die SecureFiles die Standardimplementierung der LOBs geworden. SecureFiles können komprimiert, dedupliziert und verschlüsselt werden.

Die Komprimierung basiert auf klassischen zip-Verfahren, bei der Deduplizierung werden identische LOBs lediglich einmal gespeichert. Sowohl die Komprimierung als auch die Deduplizierung fordern die Lizenzierung der Advanced- Compression-Option.

rman Compression

Hier bietet Oracle vier verschiedene Komprimierungsverfahren an, die Basic-Methode ist schon seit Oracle 8i verfügbar und nach wie vor kostenfrei. Alle anderen Verfahren sind mit Oracle 11g eingeführt worden und erfordern die Advanced-Compression-Option.

Zusätzlich werden seit Oracle 8i alle niemals genutzten Blöcke bei Nutzung der Enterprise Edition komprimiert. Die Laufzeiten und Komprimierraten sind sehr unterschiedlich.

Data Pump Compression

Die verwendeten Verfahren sind identisch zur rmanCompression. Allerdings sind beim DataPump alle Komprimierungsmethoden für Tabellendaten kostenpflichtig, während die Basisvariante zur Komprimierung der Metadaten kostenfrei ist.

Erfahrungsbericht/Lasttest

In den letzten 24 Monaten haben wir bei einigen Kunden Komprimierungen in Oracle-Datenbanken implementiert und dabei auch diverse Lasttests gemacht. Einen Auszug dieser Ergebnisse stellen wir hier dar.

Der erste Lasttest wurde auf einer Tabelle ohne LOBs durchgeführt, die mit der Advanced Compression komprimiert worden ist (siehe Abbildung 2).

Inserts wurden etwa um den Faktor 2 langsamer, Löschungen doppelt so schnell, Änderungen wurden fundamental schneller. Die Ursache dieser Verbesserungen liegt vor allem in der enormen Minimierung der Plattenzugriffe.

Der nächste Test hat sich mit der Komprimierung von Indizes befasst. Hier haben wir vor allem eine mögliche Minimierung des Plattenplatzes und damit auch eine Minimierung der Plattenzugriffe betrachtet (siehe Abbildung 3). Die Indizes wurden um bis zu 75% verkleinert. Als Konsequenz davon wurde auch die Trefferquote im Buffer Cache besser.

Der letzte Test wurde dann auf Tabellen mit LOBs durchgeführt. In diesem haben wir fünf Tabellen unter den verschiedenen Möglichkeiten getestet. Die LOBs wurden nacheinander mit den unterschiedlichen Verfahren komprimiert. Dabei hat sich gezeigt, dass man kein allgemeingültiges Komprimierverfahren empfehlen kann, die Ergebnisse sind je LOB unterschiedlich (siehe Abbildung 4). Exemplarisch zeigen wir hier die Ergebnisse für eine Tabelle (hier genannt T1). Der eigentliche Lasttest hat dann gezeigt, dass Massen-Inserts langsamer wurden, während die lesenden Zugriffe schneller wurden.

Fazit

Komprimierungen können zu sehr positiven Laufzeitverbesserungen führen, ändernde Zugriffe werden unter Umständen schlechter. Wir empfehlen jedem Kunden, der sich mit dieser Thematik auseinandersetzen möchte, einen PoC aufzusetzen, in dem die erwartete Verbesserung getestet und verifiziert wird. Wir möchten nochmals betonen, dass die kostenpflichtige Option nicht grundsätzlich für jede Variante notwendig ist. Wenn Sie Hilfe bei der Anwendung der Oracle Compression benötigen, helfen Ihnen unsere Experten unter 0 52 51 / 10 63 -0 gerne weiter.

Glossar

EE

Die Oracle Enterprise Edition bietet sowohl in Cluster- als auch in Einzelsystemen branchenweit führende Skalierbarkeit und Zuverlässigkeit. Sie verfügt über umfassendste Funktionen für OLTP und Business Intelligence und bietet gleichzeitig die niedrigste TCO.

 IOT

Index Organized Table – Eine Index-organisierte Tabelle ist ein B-Tree-Index ohne Heap-Tabelle. Hierdurch wird der Speicherplatz für die Heap-Struktur gespart.

LOB

Unter dem Oberbegriff LOB (Large Object) sind in SQL und bei Oracle PL/SQL diverse Datentypen für die Speicherung großer unstrukturierter Objekte zusammengefasst.

SE2

Oracle Standard Edition – Aus der Perspektive der Software handeltes sich bei der Oracle Standard Edition 2 (SE2) um die gleichen Binaries wie bei den Vorgänger-Editionen, jedoch ist sie aus lizenzrechtlicher Sicht ein eigenständiges, neues Produkt mit neuen Limitationen und bewährten Funktionalitäten.