In-memory ist nicht genug

Selbst bei SAP hat man inzwischen eingesehen, dass die ursprüngliche, so genial einfach erscheinende Idee, sämtliche Daten permanent im Memory zu halten, teils nicht durchführbar, teils nicht genug ist.

Sie ist etwa dann nicht durchführbar, wenn eine Datenbank in größerem Umfang historische Daten enthält, deren Laden ins Memory zu einer Kostenexplosion beim benötigten Memory führen würde.

Daten permanent im Memory zu halten genügt außerdem nicht, weil jede Datenbank die Persistenz der in ihr abgelegten Daten gewährleisten muss.

Es ist demnach notwendig, persistente Speichermedien zu nutzen, und sinnvoll, sich über die möglichst effiziente Nutzung dieses Speichers Gedanken zu machen. In der Oracle-Datenbank gibt es seit vielen Versionen schon zwei Technologien, die dieser effizienten Nutzung dienen:

Partitionierung und Komprimierung. Und es gibt zwei Technologien, weil das Wort „effizient“ zwei verschiedene Bedeutungen haben kann.

Was zusammengehört: Partitionierung

„Effiziente Nutzung des Speicherplatzes“ – das kann zunächst einmal heißen: Daten sollen so abgelegt werden, dass beim Zugriff auf noch nicht im Memory befindliche Informationen möglichst wenige I/O-Vorgänge stattfinden müssen.

„Optimierung der Datenspeicherung“ bedeutet dann, dass Daten nicht (wie es standardmäßig geschieht) in zufälliger Reihenfolge abgelegt werden, sondern unter Berücksichtigung der Frage, welche Datengruppen später wieder gemeinsam benötigt werden.

Eine Tabelle zu parti­tionieren heißt, sie in solche Teilgruppen zu zerlegen. Eine Partition beinhaltet dann beispielsweise alle Daten, die in einem bestimmten Monat neu eingefügt wurden oder einer bestimmten Filiale zugeordnet sind.

Für SAP-on-Oracle-Kunden ist die Partitionierung bei SAP BW standardmäßig eingeschaltet, sie profitieren also sofort davon. Freigegeben und unterstützt ist Oracle Partitioning aber für alle SAP-NetWeaver-Applikationen. Es kann also auch in Nicht-BW-Systemen eingesetzt werden. Für die Implementierung steht dann z. B. die SAP Partitioning Engine zur Verfügung.

Komprimierung

„Effiziente Nutzung des Speicherplatzes“ kann aber auch heißen: Daten sollen so abgelegt werden, dass sie möglichst wenig Speicherplatz beanspruchen und dass das gigantische Wachstum der Datenbanken gebremst werden kann.

Über mehrere Versionen der Datenbank-Software hinweg betrachtet, bedeutet das, dass die Effizienz der Datenspeicherung permanent gesteigert werden muss, sodass der gleiche Datenbestand von Version zu Version immer weniger Speicherplatz beansprucht.

Und eine zusätzliche Forderung heißt, dass all dies geschehen soll, ohne dass der Kunde dafür den Preis einer Performance-Verschlechterung bezahlen muss.

Bereits Oracle Database 11g setzte auf das Konzept, Werte, die mehrfach auftauchen, nicht mehrfach zu schreiben. Das gilt für Tabellen ebenso wie für Indizes. Die Komprimierungsrate, die dadurch erreicht werden kann, hängt von der Charakteristik der Daten und von der Anwendung ab.

Üblicherweise können Daten aus SAP BW (BI) stärker komprimiert werden als Daten aus SAP ERP (ECC), und SAP CRM erlaubt sogar noch größere Einsparungen. Im Schnitt benötigt eine mit Oracle Database 11g vollständig komprimierte Datenbank im SAP-Umfeld 55 Prozent weniger Speicherplatz als die entsprechende unkomprimierte.

Auf die Temperatur kommt es an

Eine häufig gestellte Frage lautet: Warum wird eigentlich die komprimierte Abspeicherung von Daten nicht zum Standard gemacht?

Einen Teil der Antwort erhält man, wenn man auf diejenigen SAP-BW-Tabellen blickt, die für das Laden neuer Daten verwendet werden. Solche Tabellen würde man gerne komprimieren, aber das würde den Ladevorgang erheblich verzögern.

Hier setzt Oracle Database 12c an, und zwar durch die Einführung eines neuen Parameters. In Version 11g kann der Anwender im Hinblick auf jede Tabelle und jeden Index die Frage beantworten, ob dieses Objekt komprimiert werden soll.

Mögliche Antworten sind „Ja“ oder „Nein“. In Version 12c wird zusätzlich die Frage gestellt, wann neue oder geänderte Daten komprimiert werden sollen. Möglich sind nun also Antworten der Art: „Ja, aber erst in einer Woche.“

Erst durch diesen neuen Parameter können die für das Laden von Daten benötigten Tabellen in die Komprimierung einbezogen werden: Geladen werden zunächst unkomprimierte Daten (keine Verlängerung der Laufzeit), die erst nachträglich, d. h. zu einem geeigneten Zeitpunkt komprimiert werden (deferred compression).

Diese Lösung wurde in Oracle Data­base 12c so generell gestaltet, dass sich mit ihr ein komplettes Information Lifecycle Management (ILM) implementieren lässt. Es stützt sich auf zwei neue Features:

• Die sogenannte Heat Map überwacht automatisch, wie intensiv Daten genutzt werden. Sie unterteilt dabei in „heiße Daten“, die häufig lesend und schreibend genutzt werden, „warme Daten“, die nur lesend genutzt werden, und „kalte Daten“, die sehr selten oder gar nicht mehr genutzt werden.
• Automatic Data Optimization (ADO) erlaubt es, genauer zu definieren, was „heiß“, „warm“ und „kalt“ bedeuten soll, und festzulegen, was beim Übergang der Daten vom heißen in den warmen oder vom warmen in den kalten Zustand geschehen soll.

Daten können bei der Veränderung ihrer „Temperatur“ auf andere Speichersysteme ausgelagert werden, ein Vorgang, der auch als „Storage Tiering“ bezeichnet wird. So lassen sich etwa kalte Daten auf langsame und damit kostengünstigere Platten auslagern.

Über die Automatic Data Optimization definiert der Datenbankadministrator Regeln, die die unterschiedlichen „Temperaturzustände“ beschreiben, beispielsweise, dass Daten, die 180 Tage lang nicht verändert wurden, als „kalt“ anzusehen sind.

„Compression Tiering“ entscheidet dann zusätzlich darüber, wie stark die angewendete Komprimierung sein soll; auch hier kann der Zeitfaktor eine Rolle spielen. Wenn Daten etwa länger als 360 Tage nicht mehr angefasst wurden, käme die stärkste Komprimierung zum Zuge.

„Innerhalb“ ist besser als „in der Nähe“

Diese umfassenden Komprimierungskonzepte und -technologien für Oracle Database 12c bieten insbesondere im Vergleich zu SAP-eigenen Lösungen Vorteile. So wird bei Hana auch die kontinuierlich wachsende Datenbank zum Problem.

Um den Produktivbetrieb nicht zu behindern, setzt SAP auf „Near-Line-Storage“, was nichts anderes bedeutet, als Daten aus der Produktivdatenbank herauszuziehen und separat zu speichern, wenn auch „nahe“ an der Datenbank. Mit Oracle Database können Daten wesentlich länger in der Produktivdatenbank gehalten werden, da sie erheblich stärker komprimiert werden können.

Oracle Exadata

Wer die Oracle-Datenbank noch weiter ausreizen möchte, ist mit den Engineered Systems von Oracle gut bedient. Die für den Datenbankbetrieb optimierte Exadata-Datenbankmaschine beherrscht noch weitere Optimierungs- und Effizienzsteigerungsmethoden:

Mit der Hybrid Columnar Compression bieten Exadata-Systeme zusätzliche, stärkere Komprimierungsalgorithmen, sodass Compression Tiering in zahlreichen Stufen möglich ist.

Zusätzlich erweitert eine Exadata die Datenbank um „Smart Storage“. Damit wird ein Teil der datenintensiven Berechnungen vom Datenbank-Server in die Storage-Server verlagert. So können etwa bei Abfragen Tabellen und Indizes, die nicht relevant sind, bereits auf Storage-Ebene ausgefiltert werden, um den I/O deutlich zu reduzieren.

Oracle Database bietet also vielfältige Möglichkeiten der Optimierung und Effizienzsteigerung für den Datenbank-Storage. Wer diese Möglichkeiten für seine SAP-Systeme einsetzt, kann die Ressourcen besser nutzen, ohne dabei auf Datenbank-Performance zu verzichten.