Oracle Database In-memory im SAP-Einsatz

Ein genauer Blick zeigt, dass es erhebliche Unterschiede in den In-memory-Konzepten von SAP und Oracle gibt. Das geht schon bei der offiziellen Benennung los:

Während Hana als „In-memory Database“ bezeichnet wird, spricht Oracle von „Database In-memory“. Welche Möglichkeiten bietet die frisch SAP-zertifizierte „Database In-memory“ von Oracle für den Einsatz mit SAP?

Grundsätzliche Gemeinsamkeit, weil grundlegendes theoretisches Konzept für die Speicherung einer Datenbank im physikalischen Hauptspeicher (RAM), ist die spaltenorientierte Ablage der Daten.

Das erklärt, warum In-memory erst in der jüngsten Vergangenheit so populär wurde. Bis vor Kurzem wurde wegen der erheblichen Nachteile der Spaltenorientierung im OLTP-Umfeld in fast allen relationalen Datenbanken auf In-memory verzichtet.

Erst der Bedarf, große Datenmengen schnell auszuwerten, der Preisverfall bei RAM sowie die Verfügbarkeit von Multicore-Prozessoren haben dazu geführt, dass dieses Konzept interessant wurde.

Hana lädt die komplette Datenbank in den Hauptspeicher, weshalb die Lösung auch In-memory-Datenbank genannt wird. Dieses Konzept benötigt spezielle Hardware, enorm viel RAM, und bei einem Server-Crash muss viel Zeit für die Wiederherstellung der Datenbank eingeplant werden.

Für den Einsatz mit Hana muss eine Datenbank komplett migriert werden. Der Weg zurück ist nur mit hohem Aufwand möglich. Die Größe des notwendigen Hauptspeichers bemisst sich übrigens nicht nur anhand des Platzbedarfs der Datenbank. Vielmehr werden für Hana-interne Funktionalitäten (Merge-Prozesse, Temp-Bereich) weitere 50 Prozent RAM zusätzlich benötigt.

RAM nicht neu für die Oracle-DB

Die Oracle-Datenbank war nie nur „Disk-basiert“. Um die Leistung zu optimieren, verwendete sie auch in bisherigen Versionen Speicher-Strukturen wie Buffer-, Row- und Result-Cache.

Mit der Oracle-Datenbank in der Version 12.1.0.2 wurde zusätzlich die In-memory Option eingeführt. Oracle Database In-memory ist damit, wie Hana, besonders geeignet, große Datenmengen schneller zu analysieren oder zu aggregieren.

Oracle nennt seine Datenbank nicht In-memory-Datenbank, sondern setzt den Begriff In-memory bewusst an das Ende des Namens. Hiermit soll deutlich gemacht werden, dass Oracle als einziger Datenbankhersteller die bestehende Technologie unverändert beibehält und um eine In-memory-Komponente erweitert.

Das bisherige Prinzip der zeilenorientierten Pufferung im Hauptspeicher und deren Speicherung auf Disk- oder Flash-Speicher bleibt dabei komplett erhalten. In einem zusätzlichen RAM-Bereich wird der In-memory Column Store eingerichtet.

Dort können vollständige Tabellen, einzelne Spalten oder einzelne Partitionen im Spaltenformat abgelegt werden. So vereint Oracle die Vorteile von zeilen- und spaltenorientierten Datenbanken in einem Produkt und schafft – im Gegensatz zu SAP – eine „hybride Datenbank“.

Diese eignet sich wie gewohnt und ohne Änderung für OLTP-Applikationen und bietet trotzdem per Column Store deutliche Performance-Gewinne bei analytischen Abfragen.

Einfach: Installation und Betrieb

Um in einer bestehenden Datenbank In-memory einzusetzen, sind lediglich zwei Schritte erforderlich: (1) Durch einen Parameter in der Initialisierungsdatei der Datenbank muss die Größe des In-memory Column Store festgelegt werden. (2) Im Anschluss werden die Tabellen ausgewählt, welche im Spaltenformat zur Verfügung stehen sollen.

Damit wird deutlich, dass eine Änderung an bestehenden Anwendungen oder Infrastrukturen, etwa für Backup- und Recovery-Operationen, für den Einsatz von Oracle Database In-memory nicht erforderlich ist.

Alle Optionen einer Oracle-Datenbank bleiben bei diesem Ansatz erhalten, wie Komprimierung, Verschlüsselung, Real Application Clusters oder Data Guard.

Hier muss mit dem weitverbreiteten Missverständnis aufgeräumt werden, dass In-memory-Technologie generell „einfach so“ zu Performance-Verbesserungen führt: Das ist weder bei Hana der Fall noch bei Oracle Database In-memory.

In der Oracle-Datenbank hilft der Oracle In-memory Advisor bei der Einrichtung. Er gibt Auskunft über Größe des notwendigen In-memory Column Store als auch Hinweise auf Tabellen, welche als In-memory-Objekte angelegt werden sollten.

Der Oracle Database Optimizer kann nun den Column Store zusätzlich nutzen, um den optimalen Zugriffspfad für die jeweilige analytische Abfrage zu finden.

Die Datenbank kann damit eine Query über den traditionellen Buffer Cache (Unique Index, Index Range Scan) oder über den In-memory Column Store ausführen. OLTP-Transaktionen werden weiterhin im Buffer Cache ausgeführt.

Die Datenbank kann individuell auf ihre Lastverteilung eingestellt werden. Das Verhältnis von analytischem und OLTP-Workload lässt sich über das Verhältnis von Buffer Cache zu In-memory Store abbilden.

Oracle Database In-memory läuft auf allen Plattformen, welche Oracle unterstützt: UNIX, Linux, Windows. Für SAP-Anwender ist die Oracle-Datenbank damit eine attraktive, weil risikolose Alternative zu Hana.

Als optimale Hardware-Plattform empfiehlt Oracle seine Exadata Database Machine. Hier lassen sich alle Vorzüge der Oracle-Datenbank, auch der In-memory-Option, voll ausreizen. Sie bietet verschiedene Speicher-Ebenen für die Datenbank: In-memory, Flash und Disk.

Über die Oracle Exadata Database Machine für SAP berichten wir in der nächsten Ausgabe ausführlich. Weitere Informationen finden Sie in dem SAP Hinweis 2178980 sowie auf http://bit.ly/oracleinfo