Foto: Oracle
Günther Stürner, Vice President Sales Consulting und Leiter der Business Unit Server Technologies bei Oracle Deutschland, sprach mit CIO.de über aktuelle Entwicklungen im Datenbankmarkt. Er sieht für den Betrieb von SAP-Systemen auf klassischen relationalen Datenbanken derzeit keine Alternative. Die In-Memory-Technologie sei noch weit entfernt davon, ein Massenmarkt zu werden.
CIO.de: Mit welchen Betriebssystemen sind Oracle-Datenbanken kompatibel?
Günther Stürner: Oracle-Datenbanken laufen auf Unix-Betriebssystemen wie AIX, HP-UX und Solaris, auf Linux-Systemen sowie auf Windows. Daran wird sich auch in Zukunft nichts ändern. Geschätzt arbeiten heute rund zwei Drittel aller SAP-Systeme mit einem Datenbankmanagement-System von Oracle, bei sehr großen SAP-Installationen ist der Anteil sogar noch höher.
SAP-Kunden: Zwei Drittel haben Oracle-Datenbank
Warum einige Marktforscher beim SAP-Betrieb die IBM DB2 und den Microsoft SQL Server als Alternative zum Datenbankmanagement-System von Oracle positionieren, erschließt sich mir nicht. DB2 hat im SAP-Umfeld einen Marktanteil von weniger als zehn Prozent. Und der SQL Server läuft bekanntlich nur unter dem Microsoft-Windows-Betriebssystem. Wenn Kunden in der Vergangenheit die Betriebssystemplattform gewechselt haben, war meist Linux die Zielplattform, sehr selten Windows. Mir ist kein Fall bekannt, bei dem ein Kunde von Unix oder Linux auf Windows gewechselt ist, um sein SAP-System auf Basis des SQL Server zu betreiben.
Marktforschern zufolge laufen immer weniger SAP-Systeme auf Unix-Betriebssystemen. Manche sagen voraus, dass diese bald vom Markt verschwinden könnten?
Stürner: Es stimmt, dass die klassischen Unix-Systeme in den letzten Jahren Marktanteile verloren haben, auch weil Linux-Systeme stark auf dem Vormarsch sind. Aber deshalb läutet für Unix noch lange nicht die Sterbeglocke. Die bevorzugten Betriebssystem-Plattformen im SAP-Umfeld für SAP-Applikationsserver sind nach wie vor klassische Unix-Systeme wie IBM AIX, HP-UX oder unsere Sparc-Solaris-Server. Danach folgen die Linux-Editionen als Unix-Derivate und Microsoft Windows.
SAP steigt durch den Zukauf von Sybase und insbesondere im In-Memory-Bereich mit HANA ebenfalls in den Datenbankmarkt ein. Was bedeutet das für die Reseller-Vereinbarung zwischen SAP und Oracle?
Stürner: Diese wird weiterhin bestehen, schon allein weil zwei Drittel der SAP-Kunden ihre SAP-Anwendungen auf einer Oracle-Datenbank betreiben. Alles andere ist reine Spekulation. Es ist kein Geheimnis, dass wir mit SAP im Wettbewerb stehen, einerseits. Doch andererseits verbindet uns seit rund 20 Jahren eine verlässliche Partnerschaft mit tausenden gemeinsamer Kunden. Abgesehen davon würde die breite gemeinsame Kundenbasis es nicht akzeptieren, dass ihnen die Arbeitsgrundlage entzogen wird.
Flexibles Lizenzmodell
SAP-Kunden können beim Erwerb von Oracle-Datenbanklizenzen zwischen zwei Optionen wählen. Sie können bei SAP eine Application-Specific-Full-Use-(ASFU)-Lizenz erwerben, die nur für die eingesetzten SAP-Systeme gilt, oder sie kaufen eine generische Full-Use-Lizenz, auf der sämtliche Business-Anwendungen aller Hersteller laufen können. Letztlich entscheidet der Kunde, welche Art von Datenbanklizenz er erwirbt. Übrigens betreiben viele Firmen ihr SAP-System mit einer Full-Use-Lizenz - auch aus Kostengründen.
Gibt es ein eigenes Oracle-Lizenzpreismodell für virtuelle Umgebungen?
Stürner: Für Kunden mit einer ASFU-Lizenz, die sich entscheiden, ihr SAP-System auf einer virtuellen statt auf einer physikalischen Maschine zu betreiben, entstehen durch den Wechsel keine Mehrkosten. Für Kunden, die mit einer Full-Use Lizenz Ihre Oracle-Systeme für SAP betreiben, gelten die aktuellen Regeln für virtualisierte Umgebungen. Im SAP-Umfeld gibt es außerdem nur sehr wenige Oracle-Kunden, die ihre Datenbankschicht virtualisieren.
Relationale Datenbanken weiter unverzichtbar
Derzeit gibt es einen regelrechten Hype um das In-Memory-Computing. Wann kommt das Ende relationaler Datenbanken?
Stürner: Es wird noch viele Jahre dauern, bis die In-Memory-Technologie eine ernsthafte Alternative zu klassischen Datenbanken sein wird. Bei dem aktuellen In-Memory-Hype wird nämlich gerne übersehen, dass die klassischen Datenbanktechnologien laufend weiterentwickelt werden. Insbesondere bei großen IT-Systemen werden Daten in einem mehrere Terabyte großen Datenbank-Cache gehalten, wodurch auch die Abfragen direkt im Cache erfolgen können. Gut eingeschwungene IT-Systeme haben bei Cache-Abfragen eine Trefferquote zwischen 90 und 95 Prozent.
In relationalen Datenbanken kommen ebenfalls In-Memory-Techniken zum Einsatz. Bei Oracle gibt es die Funktionalität des so genannten "In-Memory Query Result Cache". Damit lassen sich OLTP- und OLAP-Abfrageergebnisse als jeweils eigener Block im Hauptspeicher der Datenbank vorhalten. Stellen nun andere Endanwender die gleichen oder ähnliche Abfragen, was in der Praxis häufig vorkommt, wird dies automatisch erkannt und das Ergebnis der Abfrage, ohne erneute Ausführung des SQL-Befehls, übermittelt.
Das beschleunigt Antwortzeiten erheblich. Auch die Komprimierung von Daten ist keine Erfindung der In-Memory-Datenbanksysteme. Oracle bietet mit der Compression Option die Möglichkeit, OLTP-Daten ohne Performanceverluste zu verdichten. Noch höhere Komprimierungsfaktoren lassen sich mit der Hybrid Columnar Compression erzielen, die mit der Exadata-Datenbankmaschine zur Verfügung steht. Dadurch kann auch der Datenbank-Cache im Hauptspeicher besser genutzt werden.
In-Memory in SAP-Landschaften "winziger Baustein"
Es müssen demnach nicht alle Daten im Hauptspeicher vorgehalten werden?
Stürner: Genau. Das schlichte "alles in den Hauptspeicher" wird ja auch der Realität nicht gerecht. Meiner Meinung besteht das Modell wie Datenbanken in Zukunft betrieben werden sollen in einer Speicherhierarchie, die aus dem Hauptspeicher, großen Solid-State-Disk-Bereichen (SSDs) und Plattensystemen besteht. Wo sich welche Daten im Betrieb befinden, ist Sache des Oracle-Datenbanksystems. Wenig genutzte Daten können gemäß vordefinierten Vorgaben mit unterschiedlichen Verfahren komprimiert und in bestimmte Storage-Bereiche ausgelagert werden.
Ist In-Memory nur eine Marketing-Blase?
Stürner: Sagen wir es so: Die In-Memory-Technologie wird von einigen gern als ‚eierlegende Wollmilchsau‘ positioniert. Sie ist jedoch weit davon entfernt, eine gängige Datenbanktechnik für SAP-Softwarelandschaften zu sein. Dazu muss man sich nur die SAP-Systemlandschaften bei Kunden anschauen. Oft sind mehrere Lösungen von SAP im Einsatz, die als zwei- oder dreistufige Systeme ausgelegt sind. Hinzu kommen ABAP-basierte Eigenentwicklungen und SAP-Partnerlösungen für bestimmte Prozesse.
Innerhalb der SAP-Landschaften bilden In-Memory-Lösungen lediglich einen winzigen Baustein zur Optimierung bestimmter Anwendungen und IT-Prozesse, der relationale Datenbanktechniken ergänzt. Oracle bietet beispielsweise als Ergänzung zu seiner Exadata Datenbankmaschine sein Exalytic-System für schnelle Datenanalysen und Auswertungen an, das auch über In-Memory-Technologie verfügt.
Marktforscher sehen Potenziale von In-Memory-Computing bei der Verarbeitung und Analyse im Bereich Big Data.
Stürner: Versteht man unter Big Data große Mengen unstrukturierter Informationen mit geringer Informationsdichte, wie Social-Media-Daten oder Sensor-Daten, erfolgt deren Verarbeitung - Filterung und Aggregierung - in der Regel mit einem Hadoop-Framework oder in einer noSQL Datenbank und nicht in einer In-Memory-Datenbank. Die kommt erst, wenn überhaupt, bei der Analytik zum Einsatz. Es ist meiner Meinung nach ein großes Missverständnis, dass In-Memory Datenbanken oft mit Big Data gleichgesetzt wird. Zudem sei daran erinnert, dass die Oracle Datenbank neben den klassischen strukturierten Daten die Indizierung unstrukturierter Objekte und Texte ebenfalls unterstützt und somit auch als Textrecherche-Werkzeug eingesetzt werden kann.