Mit Hybrid Columnar Compression steht neben Advanced Compression und Basic Compression eine weitere Komprimierungstechnik für Oracle Datenbankobjekte zur Verfügung. Entscheidend für die Wahl der Komprimierungstechnik ist die Art der Datenzugriffe. DOAG Online nimmt die verschiedenen Anwendungsfälle unter die Lupe und zeigt, wie Sie diese benutzen und kombinieren.
Im aktuellen Datenbankrelease (11.2) hat man die Wahl zwischen drei Komprimierungsmethoden, die alle drei Bestandteil der Enterprise Edition sind (siehe Tabelle 1). Nur Advanced Compression wird als Option – also lizenzpflichtiges Add-On zur Enterprise Edition – angeboten.
Basic Compression und Advanced Compression können unabhängig vom Storage Subsystem genutzt werden. Hybrid Columnar Compression (HCC) ist hingegen auf genau drei Storage-Plattformen von Oracle erlaubt: Exadata Storage Server, Sun ZFS Storage Appliance (Oracle NAS Storage) und Pillar Axiom Storage (Oracle SAN Storage). Die Non-Exadata Storage-Systeme (ZFS und Pillar Storage) erfordern eine Datenbankversion ab 11.2.0.3, sowie das Patch 13041324.
Komprimierungstechnik | Verfügbar seit Version | Voraussetzung |
Advanced Compression | 11.1 | Kostenpflichtiges Add-On zur Enterprise Edition |
Hybrid Columnar Compression (HCC) | 11.2 | Enterprise Edition und Oracle Storage |
Basic Compression | 9.2 | Enterprise Edition |
Tabelle 1: Komprimierungstechniken der Oracle Datenbank 11.2
Zu den drei Komprimierungsmethoden gehören mehrere Algorithmen. Für die Komprimierung von strukturierten Daten (Tabellendaten) sind vier Algorithmen relevant. Bei der Wahl des Algorithmus spielt die Art der Zugriffe auf die Tabellendaten eine entscheidende Rolle. Die nächsten Abschnitte zeigen die typischen Einsatzszenarien von:
- Basic Compression (Basic Compression)
- OLTP Table Compression (Advanced Compression)
- Warehouse Compression (HCC)
- Archive Compression (HCC)
Komprimierung mit OLTP Table Compression
In transaktionalen Anwendungen (OLTP) überwiegen INSERT/UPDATE Operationen. Die bevorzugte Komprimierungstechnik ist hier OLTP Table Compression (Bestandteil von Advanced Compression). Dabei werden die veränderten Datensätze asynchron zur DML-Operation komprimiert – bei Erreichung eines bestimmten Füllgrades des Datenblocks. Nur Transaktionen, die die Komprimierung auslösen, sind Performance-seitig betroffen. Dieser CPU-Overhead wird an einer anderen Stelle kompensiert, denn Komprimierung spart I/O-Operationen auf die Festplatte und ermöglicht das Vorhalten einer größeren Datenmenge im Hauptspeicher. Mit OLTP Table Compression benötigt man – je nach Art der Daten (insb. Kardinalität) – zwei- bis viermal weniger Plattenplatz.
Komprimierung mit Warehouse Compression
In analytischen Anwendungen (DSS, DWH) werden die Daten mittels SELECT abgefragt und selten bis gar nicht verändert. Zwar kann man auch in diesem Umfeld OLTP Table Compression verwenden, man erzielt aber deutlich höhere Speicherplatzeinsparungen bei der Komprimierung mittels Warehouse Compression (Bestandteil von Hybrid Columnar Compression).
Dabei werden die Datensätze nicht mehr wie gewohnt rein sequentiell abgespeichert – d.h. Werte verschiedener Spalten hintereinander in einem Datenblock. Oracle verwendet bei HCC eine Kombination aus zeilen- und spaltenbasierter Speicherung. Die Datensätze werden in Gruppen aufgeteilt und innerhalb der Gruppe nach Spalten sortiert. Die Spaltenwerte der Gruppe werden im selben Datenblock abgespeichert. Diese Datenorganisation, bei der wiederkehrende Einträge vom selben Datentyp eng beieinander liegen, ermöglicht eine effizientere Komprimierung.
Warehouse Compression bietet zwei Komprimierungsstufen: LOW und HIGH. Die Plattenplatzeinsparung beträgt typischerweise sechsmal (bei Warehouse Compression LOW) bis zehnmal (bei Warehouse Compression HIGH) auf allen unterstützten Storage Systemen.
Dabei ist Folgendes zu beachten: die HCC Komprimierung kommt nur dann zum Tragen, wenn die Daten mittels Bulk Load Methoden geladen werden. Das sind folgende Verfahren: Direct Path SQL*Load, CREATE TABLE AS SELECT (CTAS), paralleles DML und INSERT mit den Hints APPEND oder APPEND_VALUES. Ändert man HCC-komprimierte Daten über konventionelle INSERT/UPDATE Operationen geht die starke HCC Komprimierung verloren. Die Daten werden weiterhin komprimiert, jedoch weniger stark.
Komprimierung mit Basic Compression
Auf fremden Storage-Systemen, auf denen Warehouse Compression nicht unterstützt ist, kann alternativ Basic Compression verwendet werden. Basic Compression geht von einer rein zeilenbasierten Speicherung der Datensätze aus; demzufolge sind die Komprimierungsergebnisse schlechter als bei Warehouse Compression. Komprimiert wird nur beim Laden über Bulk Load Methoden (s.o.).
Datensätze, die nachträglich verändert oder über konventionelle Methoden hinzugefügt werden, bleiben unkomprimiert. Deswegen eignet sich Basic Compression vor allem in read-only Umgebungen.
Komprimierung mit Archive Compression
Historische Daten, die aufgrund von gesetztlichen Vorschriften jahrelang archiviert werden müssen, sollten mit Archive Compression (Bestandteil von Hybrid Columnar Compression) komprimiert werden. Das ist die stärkste Art der Komprimierung: die Daten belegen typischerweise fünfzehnmal weniger Platz auf der Festplatte. Der reduzierte Storage-Bedarf ermöglicht es, die historischen Daten weiterhin auf Festplatte (und in der Datenbank) aufzubewahren, wo sie jederzeit abgefragt werden können.
Aus Platzgründen werden historische Daten meistens aufs Band verlegt. Dadurch stehen sie der Anwendung nicht mehr unmittelbar zur Verfügung und müssen bei Bedarf wiederhergestellt werden – ein zeitaufwändiges Unterfangen! Daten auf dem Band können eine veraltete Struktur aufweisen, wenn das Datenbankschema zwischenzeitlich verändert wurde. Das macht den Wiederherstellungsprozess noch mühsamer. Bei Daten, die mit Archive Compression komprimiert wurden, ist der CPU-Overhead bei DML-Operationen recht hoch. Deswegen sollte man Archive Compression auf Daten anwenden, die eher selten abgefragt werden.
Je nachdem, ob die Tabellendaten verändert, gelesen oder nur aufbewahrt werden, wird man sich für die Komprimierung mit Advanced Compression, Basic Compression oder Hybrid Columnar Compression entscheiden. Die Komprimierungsverfahren sind hier zusammengefasst:
Komprimierungsmethode | Syntax für CREATE TABLE oder ALTER TABLE (11.2) | Anwendungsfall | Verhältnis* |
[Advanced Compression] OLTP Table Compression | COMPRESS FOR OLTP | OLTP-Umfeld: Daten werden hinzugefügt und verändert | 2-4 |
[Hybrid Columnar Compression] Warehouse Compression | COMPRESS FOR QUERY [LOW|HIGH] | Data Warehouse-Umfeld: Daten werden überwiegend gelesen | 6-10 |
[Hybrid Columnar Compression] Archive Compression | COMPRESS FOR ARCHIVE [LOW|HIGH] | Historische Daten: seltener Zugriff | 15 |
Basic Compression | COMPRESS [BASIC] | Data Warehouse-Umfeld: Daten werden überwiegend gelesen | 2-4 |
*zwischen unkomprimierten und komprimierten Tabelle (typische Werte)
Tabelle 2: Komprimierungsverfahren im Vergleich
Komprimierung einer Tabelle mit mehreren Komprimierungsmethoden
Es ist möglich, mehrere Komprimierungsmethoden auf dieselbe Tabelle anzuwenden. Dafür muss die Tabelle partitioniert sein. Jede Partition hat ihre eigenen Komprimierungseigenschaften. So wird eine ERP-Anwendung aktuelle Daten, die sich häufig ändern, in Partitionen mit OLTP Table Compression speichern. Ältere Daten, die kaum noch angefasst werden, werden in Partitionen mit Archive Compression aufbewahrt.
Ein Data Warehouse auf Exadata oder auf Oracle Storage speichert häufig abgefragte Daten in Partitionen mit Warehouse Compression; historische Daten hingegen werden in Partitionen mit Archive Compression abgelegt.
Der Compression Advistor: Komprimierungsalgorithmen testen
Die Oracle Datenbank bietet ein nützliches Werkzeug, um das Einsparpotenzial der verschiedenen Komprimierungsalgorithmen auf Tabellen Ihrer Datenbank zu evaluieren. Der Compression Advisor ist Bestandteil der Datenbankversion 11.2 (PL/SQL-Package DBMS_COMPRESSION). Damit lässt sich die Kompressionsrate von OLTP Table Compression und von HCC testen, letzeres auch ohne Zugriff auf Exadata oder Oracle Storage. Die Nutzung des Compression Advisors ist in einem Artikel der Oracle DBA Community näher beschrieben.
Ausblick
Zusätzlich zu den vorgestellten Methoden zur Komprimierung von Tabellendaten, bietet die Oracle-Datenbank noch mehr Möglichkeiten, Platz zu sparen. Indizes lassen sich in jeder Datenbankedition (Standard Edition One, Standard Edition, Enterprise Edition), schon seit Version 8i, komprimieren. Unstrukturierte Daten (wie Bilder, Textdateien, Musikdateien, Videos) und semistrukturierte Daten (wie XML-Dokumente) können mit Advanced Compression ebenfalls komprimiert werden. Die Voraussetzung ist, dass sie als SecureFiles gespeichert wurden. SecureFiles ist die optimierte Storage-Architektur für Large Objects seit Version 11.1. Auch Datensicherungen mit dem Recovery Manager (RMAN) oder mit Data Pump können platzsparend abgelegt werden. Die optimierten Komprimierungsverfahren zu diesem Zweck sind Bestandteil von Advanced Compression. Nicht zuletzt erlaubt Advanced Compression die Komprimierung des Datenverkehrs zwischen der Primary und der Standby Datenbank in einer Data Guard Konfiguration, um Bandbreite zu sparen.
Fazit
In der Oracle Datenbank 11.2 Enterprise Edition bei Verwendung von Oracle Storage kann man sowohl Hybrid Columnar Compression als auch Advanced Compression für die Komprimierung von Tabellendaten verwenden. Hybrid Columnar Compression eignet sich für Data Warehouse Umgebungen und für Datenarchive. Mit Advanced Compression lassen sich Tabellendaten in transaktionalen Umgebungen, aber auch unstrukturierte Daten, Backups und der Netzwerkverkehr zur Standby Datenbank komprimieren. Beide Technologien können kombiniert werden, um maximale Speicherplatzeinsparungen und gute Performance zu erzielen.
