Hana triumphiert, MaxDB lebt weiter
Was bedeuten die neuen SAP-Pläne nun für Anwender, die schon immer auf SAP-Datenbanken gesetzt haben? Wie sollten sie die eigene IT-Strategie auf jene der SAP abstellen?
Es mehren sich Stimmen, die Anwendern einreden wollen, gerade MaxDB sei ein Auslaufmodell. Wird dann zum DB-Wechsel geraten, ist eigenartigerweise oft gar nicht von Hana die Rede, vielmehr wird ASE als vermeintlich naheliegendes Migrationsziel empfohlen.
Fakt ist aber: ASE ist keine wirkliche Alternative zu MaxDB, und MaxDB stellt noch auf Jahre ein verlässliches und sinnvoll nutzbares DBMS dar.
Die späten 80er: SQL überlässt SAP den anderen
Zum Zeitpunkt der Entstehung von R/3 Ende der 1980er-Jahre war die Datenbankstrategie von SAP noch klar und einfach. SAP war damals ausdrücklich kein Datenbankhersteller, sondern setzte als ERP-Anbieter auf die etablierten SQL-Datenbank-Management-Systeme.
Anfänglich waren das nur Oracle und Informix, später auch IBM DB2 und Microsoft SQL Server.
Der Umstand, dass Oracle mit Financials bereits Ende der 1980er-Jahre auf den Markt kam und damit SAP auf dem Gebiet der Applikationen Konkurrenz machte, wurde zunächst als marktübliche „Coopetition“ abgetan.
Im Laufe der Jahre entwickelte sich SAP jedoch zum größten Value Added Reseller für Oracle – und überwies jährlich einen beträchtlichen Millionenbetrag an den Wettbewerber. Ein Dilemma, das SAP dazu bewog, bei ihrer Strategie der Datenbankabstinenz umzusteuern.
Die 90er: SAP-eigene DB
Mit ADABAS D von der Software AG holte sich SAP Anfang 1992 eine weitere Datenbank ins Haus. Nach der R/3-Zertifizierung 1994 wurde sie zunächst als kostengünstige Alternative zu Oracle & Co. positioniert.
Nachdem SAP 1997 dann die Produktrechte und einen Großteil des Entwicklungsteams von der Software AG übernommen hatte, hörte SAP auf, bloßer Reseller fremder Datenbank-Management-Systeme zu sein.
Das erste SAP-eigene DBMS wurde fortan unter dem Namen SAP DB angeboten.
Das offenkundige Ziel von SAP war es dabei, den Wettbewerb im Datenbankumfeld anzufachen und durch das eigene Produkt die Dominanz von Oracle in der SAP-Kundenbasis zu brechen.
Nachdem die Absatzzahlen nicht spürbar anziehen wollten, veröffentlichte SAP im Jahr 2000 die Version 7.3 von SAP DB unter einer Open-Source-Lizenz.
2003: Open-Source- Wiedergeburt
2003 folgte eine Vertriebskooperation mit MySQL AB. In deren Rahmen wurde das DBMS – ab Version 7.5 – als „MaxDB by MySQL“ angeboten. Support und Weiterentwicklung verblieben jedoch bei SAP.
Diese Kooperation wurde 2007 sang- und klanglos beendet, und von der Version 7.6 an wurde SAP MaxDB auch nicht mehr quelloffen angeboten. Allerdings entschied sich SAP damals, eine Alternative zu offerieren, um MaxDB außerhalb von SAP-Anwendungen weiterhin nutzbar zu machen: als kostenlose „Community Edition“ unter einer Community License.
Bis heute ist MaxDB in Form dieser kostenlosen Community Edition erhältlich – und damit auch außerhalb der SAP-Welt einsetzbar.
Weil SAP lange Zeit gar nicht als DB-Hersteller wahrgenommen werden wollte, fristete MaxDB seine Existenz weitgehend im Verborgenen. Dem Erfolg hat das allerdings kaum Abbruch getan.
Trotz fehlendem Push durch Marketing und Vertrieb von SAP hat sich die Datenbank durchaus verbreitet. Vor allem im deutschsprachigen Mittelstand erfreut sich MaxDB ungebrochen hoher Akzeptanz.
Wichtige Gründe dafür sind die günstigen Gesamtbetriebskosten (neudeutsch „TCO“) und ein geräuschloser, zuverlässiger Betrieb. Bei SAP-Kunden sind mindestens 27.000 MaxDB-Server im Einsatz.
Diese Zahl ist übrigens um ein Vielfaches höher als die der SAP-ASE-Installationen in der Kundenbasis. Auch SAP-intern hat sich MaxDB mit mehr als 2.500 Installationen weit verbreitet. Insider-Informationen zufolge basiert rund die Hälfte der SAP-internen Produktionssysteme auf diesem DBMS.
SAP-Neuentwicklungen auf MaxDB
Auf Basis des MaxDB-Kernels nahm SAP auch technologische Neuentwicklungen vor. So entstand Ende der 1990er-Jahre SAP liveCache als objektbasierte Erweiterung des MaxDB-Kerns für das In-Memory-Management komplexer Objekte (i. e. Bäume und Netze) – dediziert für die Logistiklösung SAP SCM/APO.
Derzeit existieren noch über 5.000 Installationen von SAP liveCache im Kontext von Supply Chain Management und Advanced Planning & Optimization.
Auch im Zusammenhang mit SAP Content Server spielt MaxDB nach wie vor eine besondere Rolle: ohne MaxDB keine Auslagerung von unformatiertem Content in eine Datenbank.
Über dieses Einsatzszenario sind zwar keine offiziellen Zahlen verfügbar, aber man wird von einigen tausend oder sogar mehr als zehntausend Installationen ausgehen dürfen. SAP MaxDB führt vielleicht keine Existenz im Scheinwerferlicht, aber dem Zuspruch der Anwender hat das nicht geschadet.
In den vergangenen Jahren ist die installierte Basis von SAP MaxDB sogar deutlich gewachsen: allein seit Anfang 2013 um über 50 Prozent. Einer der Gründe dafür spiegelt sich auch in der kürzlich durchgeführten Studie „Relational OLTP-Midmarket DBMS“ der Analysten von „Research in Action“ wider: MaxDB erfreut sich einer anhaltend hohen Kundenzufriedenheit.
Sybase bringt ASE und IQ mit
Zum Ende der ersten Dekade 2000 unternahm SAP eine milliardenschwere Akquisition von strategischer Relevanz: Per 30. Juli 2010 wurde der kalifornische Datenbankhersteller Sybase übernommen.
Erklärtes Ziel von SAP war es, dadurch „Milliarden von Nutzern zu erreichen“.
Wenngleich die Mobility-Lösungen und der Zugang zu Mobilfunk-Kunden das Hauptmotiv für die Übernahme bildeten, holte sich SAP mit dem Deal auch die originären Datenbankprodukte von Sybase ins Haus.
Dazu gehörten OLTP-DBMS Sybase Adaptive Server Enterprise (ASE) und die Datawarehouse-Datenbank Sybase IQ, die sich aufgrund ihrer spaltenorientierten Speicherorganisation durch hohe OLAP-Performance auszeichnete.
Aber die Akquisition von DBMS-Technologie war eher „Beifang“ und kein Baustein der – seinerzeit noch nicht offiziell verkündeten – Strategie, im Datenbankmarkt an vorderster Front mitmischen zu wollen.
Was genau SAP mit den erworbenen DBMS-Produkten eigentlich vorhatte, ist bis heute unklar. Jedenfalls war es nie ein erklärtes Ziel, MaxDB durch Sybase ASE ablösen zu wollen.
SAP tritt wieder als DB-Hersteller auf
Schon zur Mitte der ersten Dekade des neuen Jahrtausends war es Hasso Plattner gelungen, Zustimmung zur Realisierung seiner Vision einer hochperformanten, spaltenorientierten In-Memory-Datenbank zu finden.
Entsprechend hatte SAP schon 2005 insgeheim den kalifornischen Softwarehersteller Transact in Memory und damit die In-Memory-OLTP-Datenbank P*TIME gekauft.
2009 machte man sich bei SAP daran, eine neue SAP-Datenbank aus der Taufe zu heben – als Technologiegemenge aus dem Row-Store-DBMS P*Time, aus der bereits Jahre zuvor entwickelten, Column-Store-basierenden Suchmaschine TREX und aus MaxDB als Persistenzschicht.
Zunächst führte diese neue SAP-Datenbank nur den Namen New Database bzw. New DB. Bei ihrer ersten Auslieferung im November 2010 trug sie vorübergehend den Namen High Performance Analytical Appliance.
Später wurde sie nur noch mit der Kurzform dieses Namens bezeichnet: SAP Hana 1.0.
Die Zukunft gehört Hana
Spätestens seit der Vorstellung von Hana ist es eindeutig: SAP tritt offensiv als Datenbankhersteller in Erscheinung und hat Oracle, dem Hauptwettbewerber auf diesem Gebiet, den Kampf angesagt.
Erklärtes Ziel ist es dabei, SAP-Anwendungen von traditionellen RDBMS zu befreien, seien es die eigenen oder die der Wettbewerber. Aus diesem Grund investiert SAP schwerpunktmäßig in die moderne Hana-Plattform und kaum noch in die Weiterentwicklung ihrer klassischen relationalen Datenbanken.
Die Konsequenz aus dieser unmissverständlichen Hana-Strategie ist klar: Langfristig betrachtet gibt es für keine der betagteren SAP-Datenbanken eine Perspektive, weder für MaxDB noch für die Sybase-Erbschaften ASE und IQ.
Die Datenbankzukunft der SAP heißt Hana. Wer seine betriebswirtschaftlichen Anwendungen weiter von SAP beziehen will, kommt an Hana nicht vorbei.
Mit der Ankündigung von S/4 Hana, der Business Suite der nächsten Generation, hat die SAP SE nochmals ihren Anspruch unterstrichen, auf ihrem Turf die Datenbankhoheit durchzusetzen.
MaxDB: Mindesthaltbarkeit 2025
Bleibt die Frage, welchen Handlungsdruck die SAP-Ausrichtung auf Hana jetzt für Unternehmen verursacht, die derzeit MaxDB einsetzen. Aktuell keinen besonderen.
Erst Anfang 2015 hat SAP die „Mainstream Maintenance“ um fünf Jahre bis Ende 2025 verlängert – und garantiert damit die Wartung für mindestens weitere zehn Jahre.
Häufiger wird die Behauptung vorgetragen, die Weiterentwicklung von MaxDB sei eingestellt.
Das ist offensichtlich falsch. So wurde beispielsweise Database Studio, das Standalone-Management-Tool für MaxDB, von SAP jüngst um ein grafisches Analysetool erweitert.
Eine weitere einfache Möglichkeit, einer MaxDB-Instanz einen Performance-Boost zu verpassen, stellen Flash-Speicher-basierende Solid-State-Disks dar.
Der Wechsel von HDD auf SSD ist natürlich keine Weiterentwicklung des DBMS im eigentlichen Sinn, er wird aber jetzt möglich, weil SAP jüngst die entsprechende Hardware zertifiziert hat.
ASE ohne Kostenvorteil
Des Öfteren ist zu hören, eine Migration von MaxDB auf ASE sei sinnvoll. Immerhin ist in jeder „Hana Runtime Edition for Applications and SAP BW (REAB)“ bereits jeweils eine Lizenz für MaxDB und für ASE enthalten – die Migration wäre also lizenzkostenneutral möglich, ebenso wie der Parallelbetrieb beider DBMS.
Angesichts der eindeutigen Fokussierung von SAP auf Hana stellt aber eine solche Migration keine lebensverlängernde Maßnahme dar: Der Lebenszyklus von ASE dürfte zeitgleich mit dem von MaxDB zu Ende gehen.
Als Hauptargument für eine Migration führen ASE-Befürworter meist die Datenkomprimierung an. Aber es gilt immer noch das amerikanische Sprichwort: „There’s no such thing as a free lunch.“
Die Ersparnis an Plattenplatz ist teuer erkauft, weil ASE eine deutlich höhere Rechenleistung erfordert. Der Komprimierungsvorteil von ASE wird letztlich mit Investitionen in CPU-Power bezahlt.
Das Backup-Problem von ASE
Aus Sicht eines MaxDB-Befürworters ist das Backup-Konzept von ASE eine seiner größten Schwachstellen.
ASE kann während einer Vollsicherung das Log nicht leeren. Dies bedeutet: Wenn das Backup zu lange dauert, laufen die Logs über und es kommt zu einem Systemstillstand.
Im Unterschied dazu kennt die Online-Backup-Einrichtung von MaxDB derartige Beschränkungen nicht. Die Empfehlung, man solle ASE-Backups doch in Zeiten geringer Belastung machen, klingt schlicht naiv und geht an den betrieblichen Realitäten vorbei.
Wenn Migration, dann auf Hana
Es zeigt sich also, dass ASE häufig überschätzt wird, während die Fähigkeiten von MaxDB notorisch unterbewertet bleiben.
Ein Gewinn an Funktionalität lässt sich bei einer Migration von MaxDB zu ASE nur in wenigen exponierten Ausnahmefällen erzielen – beispielsweise wenn die höhere Komprimierung ein entscheidender Faktor ist.
Dagegen stehen höhere Lizenz- und Wartungskosten (sofern die Lizenz nicht im Rahmen einer Hana Runtime Edition kostenneutral erworben wird), der notwendige Ausbildungsaufwand sowie beträchtliche Risiken.
Anwender, die MaxDB nicht nur mit ERP, sondern auch in Form von liveCache oder im Rahmen von Content Server einsetzen, könnten sowieso nicht vollständig zu ASE migrieren.
Solange SAP ihre internen, MaxDB-basierenden Systeme nicht auf breiter Front nach Hana migriert, können MaxDB-Anwender ruhig schlafen. Wer heute MaxDB einsetzt, sollte so lange dabei bleiben, bis ihm der Umstieg auf Hana geboten scheint.
Eine zweifache Migration wäre indes völlig abwegig. Für das Ziel Hana den Umweg über ASE zu nehmen, bleibt unsinnig.
