Seit mehr als 25 Jahren beschäftige ich mich mit Datenbanken. Klar gab es damals eine Reihe von Datenbanken, dBase, FoxPro, Postgres, Informix usw.. Kommerziell haben sich aber nur DB2 von IBM, MS-SQL von Microsoft, Teradata und vor allen die Datenbank von ORACLE durchgesetzt.
Ich habe mich hauptsächlich mit ORACLE beschäftigt und damit so ziemlich jede Aufgabe gelöst. Natürlich habe ich auch mit anderen Datenbanken gearbeitet: ein Data Warehouse mit Teradata, TimesTen für Echtzeit-Datenerfassung, MySQL für einen Webshop usw.
Meinen Kunden habe ich auch immer versucht, die Datenbank vorzuschlagen, die für ihr Vorhaben mir am besten geeignet schien, halt die mit dem besten Kosten-Nutzen-Verhältnis. Meist war es ORACLE, weil alles andere kam kaum in Frage, DB2 gabs nur für Grossrechner oder teure AIX-Maschinen, MS-SQL war auch nicht gewünscht, weil man lieber UNIX-Server als Windows-Server haben wollte oder die Anwendung lief damit nicht. TimesTen und Terradata waren zu speziell und MySQL war (noch) nicht „business-ready“.
Seit mehreren Jahren drängen nun viele andere Datenbanken in den Markt: PostgreSQL, MariaDB, Mongo-DB, NO-SQL-Datenbanken, Cassandra und auch Datenbankservices für verschiedene Zwecke in der AWS-Cloud usw..
Eigentlich für mich als Datenbank-„Fuzzi“ eine komfortable Situation, die Auswahl ist nun grösser und ich kann einem Kunden mehrere Varianten vorschlagen.
Allerdings kam mit den Datenbankalternativen eine gewisse Stimmungsmache gegen ORACLE auf. Schon davor kam Diskussionen und Skepsis auf, diese wurde von Jahr zu Jahr heftiger und schlug in einen fast schon feindlichen ja aggressiven Ton um.
Mir selbst schlug diese Stimmungsmache und Aggressivität entgegen bei einem festen Engagement, bei dem ich für das Unternehmen den ORACLE-Stack neu konzipieren, härten und optimieren sollte. Allein nur weil ich im ORACLE-Umfeld tätig war, schlug mir von meinem Chef und danach auch von einigen Kollegen erst Skepsis und dann Feindseligkeit entgegen.
Was ist da passiert? Aus meiner Sicht begann es eigentlich recht harmlos: Mit dem Aufkommen von objektorientierter Programmierung und JAVA kollidierte die OO-Sicht mit der relationalen Speicherung von Daten in der Datenbank. Man entwickelte Klassen für die Transformation zwischen beiden Welten, wie z.B. Hibernate. Diese waren dann die Persistenzschicht, also der Layer, der die Daten abspeichert. Damit wurde der Umgang mit Datenbanken abstrahiert. Die Entwickler verloren den Fokus auf ein performantes Datenmanagement, getreu dem Motto „das macht die Java-Klasse“. Meines Erachtens leider eine fatale Sicht bei den immer grösser werdenden Datenvolumen, die verarbeitet werden müssen. Hinzu kam, dass man bei der Entwicklung uns Datenbanktypen aussen vorgelassen hat, auch weil die „Java-Klasse macht das ja“…. Also wurden dann die fertigen JAVA-Apps für den Betrieb „über den Zaun geworfen“. Naja und dann kamen halt im Betrieb die üblichen Probleme, die mit steigendem Datenvolumen so einhergehen: Lange Wartezeiten und Timeouts. Was kannst du da als DBA (Datenbankadministrator) machen? Wenn man Glück hat, hilft ein Index oder zwei. An die Query kommt man meist nicht ran, die ist im JAVA-Quellcode. Mit Chance bekomme ich die Query vom Entwickler oder aus dem Trace. Dann kann ich diese optimieren und den optimalen Execution Plan der ursprünglischen Query unterschieben (Ja das geht in ORACLE, und so weit ich weiss nur in ORACLE).
Ich habe mal für einen Versandhändler gearbeitet und dieser wollte auf seiner Online-Plattform mit einem Gewinnspiel E-Mail-Adressen für seine Newsletter sammeln. Der Entwickler, man nannte ihn „Gott“, weil er virtuos in JAVA programmieren konnte, hatte die Komponente erstellt und immer in der Nacht von Donnerstag auf Freitag wurde so etwas deployed. Ja und um 11 Uhr vormittags stand der Shop. Was war passiert ? Vor dem Eintragen der Mailadresse in eine Tabelle wurde geprüft, ob diese Mailadresse schon eingetragen war. Und auf der Tabelle war kein Index. Also jede Abfrage ein Full Table Scan und die Tabelle wurde immer grösser und damit dauerte das Eintragen immer länger. Und wir als Web-User sind ja nicht gerade geduldig, wenns länger dauert, einfach noch mal Refresh drücken, und der Prozess beginnt von vorn, was das Problem weiter verschärft. Ich habe dann einen Index angelegt, das dauerte 30 Sekunden, damit war das Problem in der Datenbank behoben. Die Applikationsserver waren aber so zu, dass man sie durchstarten musste. Der Shop war insgesamt ca. 2 Stunden weg, in denen kein Umsatz generiert werden konnte. Ich bin dann zu „Gott“ und habe ihn gefragt, ob er getestet hat. Klar hat er, die Funktionalität, aber keine Mengentests. „Gott“ hat von da an immer Funktions- und Massentests gemacht. Trotzdem wurde in den höheren Etagen die Ursache in der Datenbank ausgemacht, weil die Funktion war ja fehlerfrei, die Datenbank hat länger gebraucht beim Ergebnis finden. Solche Situationen habe ich schon mehrere erlebt. Ich nenne das den „Datenbank-Knick“. Immer dann, wenn ich das Problem in der Datenbank lösen konnte, dann war die Datenbank auch am Problem „schuld“. Und wenn nicht, war sie es trotzdem.
Und dann kamen die Opensource-Datenbanken, Die lassen sich kostenlos aus dem Internet runterladen und installieren, meist mit einem Kommando, nämlich yum. Dann gibt es da noch Tools wie PHPMyAdmin (für MySQL) oder pgAdmin (PostgreSQL), ebenfalls frei installierbar. Damit kann man sich eine Datenbank erzeugen und ein paar Tabellen, den Rest überlässt man der Persistenzsschicht. Das geht alles schnell und einfach und man braucht keinen DBA. Klar, dass das die Entwickler begeistert. Und irgendwann auch die Chefs. Und die fragten sich dann auch bald: Wieso zahlen ich soviel Geld für ORACLE-Datenbank-Lizenzen?
Jetzt kam der Wind von zwei Seiten, die Entwickler warfen weiterhin und noch schneller ihre Apps über’n Zaun, diesmal mit Cassandra oder MariaDB oder PostgreSQL oder gar eine NoSQL-Datenbank als „Daten-Layer“. Das allein ist nicht das Problem. Das Problem ist dabei, dass dann im Betrieb dieser Datenbanken auftretende Performanceprobleme nicht so einfach zu lösen sind wie bei ORACLE. Ja einen Index anlegen geht da auch, hilft aber nicht immer. Und dann geht das „Gebastel“ los. Klar man kann PostgreSQL „kostenlos“ skalieren, naja Rechenleistung in der Cloud braucht es auch und die muss bezahlt werden und PostgreSQL-Skalierung On-Premise heisst Hardware-Erweiterung, die ist auch nicht unbedingt kostenlos. Dann gibt es noch eine Reihe von Erweiterungen, die man installieren kann, die kommen von verschiedenen Entwicklern und sind auch nicht alle kostenlos. D.h. man muss rausfinden, welche Extention einem hilft. Dann kann man noch die Community fragen, das kann aber etwas dauern. Oder man fragt einen Spezialisten. Das kostet auch Geld, mindestens aber Zeit.
Nach meiner Erfahrung kann ich feststellen: Die Kostenwelle bei freien Datenbanken kommt später, nämlich im Betrieb, während die Kosten bei ORACLE (Lizenzen & Wartung) bei der Anschaffung, also vor dem Betrieb, kommen. Leider nimmt der Mensch aber die Anschaffungskosten stärker wahr als die Betriebskosten….
Von der anderen Seite kam die Chefetage mit der Frage: Wie kann man ORACLE durch Opensource-Datenbanken ersetzen? Ich bin auch gerade mit so einem Plan konfrontiert, der die Ablösung von ORACLE vorsieht. Wenn es selbstentwicklete Software ist, kann man versuchen, die Datenbank z.B. in PostgreSQL zu migrieren, da sich ORACLE und PostgreSQL „ähneln“. Da gibt es auch Tools für die Konvertierung. Bei Datentypen funktioniert das recht gut. Bei der Umwandlung von etwas komplexeren Views und PL/SQL geht es schon nicht mehr. Also baut man alles von Hand um, was dauert und damit kostet.
Bei Datenbanken, die von Dritt-Anbieter-Apps benötigt werden, kann man nur den Hersteller fragen. Bisher habe ich dabei immer erlebt, dass solche Anfragen mindestens 50:50 ausgingen, Eine Hälfte lässt sich umstellen auf eine Opensource-Datenbank, die andere Hälfte nicht. Also bleibt einem ORACLE weiter erhalten. Hat man dann ein Engineered System (Exadata oder ODA) im Rechenzentrum stehen, wäre eine Umstellung wirtschaftlich nicht empfehlenswert, da die Lizenzkosten gleich bleiben, bei weniger Datenbanken. Damit kostet jede verbliebene Datenbank mehr als vorher. Hier sollte man eher nachdenken noch mehr ORACLE-Datenbanken auf das System zu bringen, also eher von Opensource auf ORACLE umstellen. So kann man meines Erachtens die Lizenzkosten effizient nutzen.
Leider scheint aber der Zug für solche Überlegungen abgefahren zu sein. Der Hype „Nur noch Opensource“ oder auch „Bloss nicht ORACLE“ scheint voll im Gange. Und wenn dann noch ein DBA wie ich damit kommt, der fast nur mit ORACLE gearbeitet hat, dann hören ihm erst recht weder Entwickler noch Chefs oder Entscheider zu.
Naja, dass es zu dieser Situation kam, hat wohl auch ORACLE’s Haltung zur Lizenzierung von ORACLE-Produkten auf VMWare zu tun. Neben dem Einsatz von Opensource ist Virtualisierung ein weiterer Baustein zur Kosteneinsparung. Und ein grosser Player, wenn nicht der Player für Virtualisierung ist VMWare. Mit Virtualisierungssoftware ist es möglich, dass mehrere Server virtuell (sogenannte VMs = Virtuelle Maschine) auf einer Hardware ausgeführt werden. Sie teilen sich die Ressourcen (CPU, Speicher etc.), was die Kosten für die Hardware reduziert.
ORACLE steht bei VMWare (und soviel ich weiss auch bei Hyper-V von Microsoft) nun auf dem Standpunkt, dass man, wenn man z.B. eine ORACLE Datenbank auf einer VMWare-Virtualisierung laufen lässt, muss man alle Prozessoren aller VMWare-Nodes lizensieren, da die VM mit der ORACLE-Datenbank drauf theoretisch auf jedem Prozessor laufen könnte ("Oracle Partitioning Letter") . D.h. also, wenn man auf einer Hardware-Farm mit 100 CPUs virtualisiert, und man dort eine VM mit einer ORACLE-Datenbank installiert, die vielleicht 2 CPUs benötigt , muss man laut ORACLE alle 100 CPUs lizensieren. Das ist keine Kostenreduktion, sondern eine Kosten-Explosion. Nachvollziehen kann ich diese Praxis nicht ganz. Eine Lizenzpraxis, wie z.B. bei IBM’s LPAR oder der ORACLE eigenen Virtualisierung ORACLE VM, für alle Virtualisierungsanbieter würde den aktuellen Gegenwind für ORACLE erheblich abflauen lassen.
Neben dem Simplifizieren, der Kostensenkung durch Opensource und ORACLE’s komischen Lizenzregeln beim „Fremd“-Virtualisieren gibt es noch ein paar andere Gründe, warum ORACLE verteufelt wird. In den letzten 25 Jahren habe ich da schon ein paar kuriose aufgedeckt, von allein sagt einem das niemand, höchstens bei ein paar Bier am Abend und unter vier Augen. Da gab es z.B. Entwickler, die nicht wussten, wie man eine ORACLE-Datenbank installiert. Ja früher war das nicht einfach, und das war hängen geblieben, heutzutage kann ein Huhn ORACLE installieren, man muss nur ein paar Körner auf die ENTER-Taste legen., und natürlich geht das jetzt auch mit yum.
Dann sollte ich an der Abschaffung von ORACLE mitwirken.Man hatte eine ExaData und wollte Oracle abschaffen ? Nach einer Weile fand ich raus, dass die ExaData nicht im eigenen Rechenzentrum stand, sondern bei einem Provider. Ja und der hatte wohl nicht so viel KnowHow in ExaData, jedenfalls liessen seine Jobgesuche für einen ExaData-Engineer drauf schliessen. Aber miteinander darüber gesprochen haben Provider und Eigner der ExaData nicht. Für den Eigner sah es so aus, als ob das ORACLE-„Zeugs“ nicht richtig funktioniert und war entsprechend sauer, natürlich auf ORACLE, Tenor: „Ein Haufen Geld und kein Service“ . Wer denkt da nicht dran, den „Krempel“ wieder los zu werden.
Ja und dann gibts noch die Entwickler, die partout keine Funktionen einer Datenbank benutzen und diese lieber in JAVA nachbilden. Als Argument wird dann immer aufgeführt, dass so die Datenbank jederzeit austauschbar ist. Kann man machen, aber man verliert dabei Performance und zwar nicht nur bei ORACLE sondern mehr oder minder bei allen Datenbanken. Datenfunktionen (Analytische, OLAP usw. ) sind in Datenbanken effiizient integriert, weil nahe an den Daten. Keine Programmiersprache kann dem das Wasser reichen. Ich halte es daher für eine bessere Idee, sich bei seiner App-Entwicklung auf ein paar Datenbanken zu fokussieren, dann abber deren Datenfunktionen zu benutzen und auch deren Programmiersprache.
Für mich ist dieses ORACLE-„Bashing“ völlig unangebracht. Ich habe fast mein ganzes Berufsleben mit Datenbanken und anderen Produkten von ORACLE zu tun gehabt. Bisher gab es immer eine Lösung, entweder mit irgendwelchen Komponenten (z.B. Data Masking, InMemory, usw.) oder mit simplem Tuning-Handwerk oder mit dem ORACLE Support. Klar kostet das Lizenzen und Wartung, dafür bekommt man aber auch ein System, mit dem ein sicherer und stabiler Betrieb garantiert wird. Des Weiteren deckt ORACLE mit seiner Datenbank nahezu jeden Anwendungsbereich ab. Deswegen ist es völliger Unsinn und ein grosser Fehler , diese Datenbank von vornherein auszuschliessen.
Auch das Abschaffen von ORACLE sollte überlegt sein und man sollte vorher wissen, was das für den eigenen Betrieb zeit- und kostentechnisch bedeutet. Ich hatte schon ein paar Anfragen früherer Kunden, die gern wieder auf ORACLE Datenbanken zurück wollten…..
Natürlich haben alle anderen Datenbanken ob nun Opensource oder nicht auch ihre Daseinsberechtigung. Es kommt drauf an, die richtige Datenbank für den jeweiligen Zweck zu finden und mit dieser dann die App oder das System zu realisieren und dabei auch die Vorzüge der Datenbank in der Programmierung auszunutzen.
Natürlich kommt man bei solchen Realisierungen an Punkte, wo man etwas nicht weiss bzgl. Datenbanzugriff oder -abfrage oder was auch immer. Das ist kein Beinbruch, dafür gibts solche Leute wie mich, die kann man alles fragen. Es gibt keine dumme Fragen nur dumme Antworten.
Ich denke nur so kann man gute Projekte realisieren: zusammen ohne Aggressionen und ohne Vorurteile. Jeder macht mal Fehler: ich, der ein oder andere Entwickler, ORACLE.
Egal, irgendwann merkt man es und korrigiert es …hoffe ich.
