6 Minuten Lesezeit (1154 Worte)

Die Fesseln sprengen? Wie migriere ich eine Datenbank?

Freitag, 03. Juli 2020

In der letzten Zeit häufen sich die Anfragen von Kunden, ob eine Migration eines kommerziellen Datenbankproduktes in eine Open-Source-Datenbank möglich ist. Die Gedanken dahinter drehen sich oft um infrastrukturelle Änderungen (Cloud vs. On-Premises) und/oder um den Wunsch, Kosten (Lizenzen) einzusparen.

Die technische Antwort (eines DBAs) auf diese Frage lautet: Ja, natürlich ist das möglich.

Das Problem ist jedoch die zu kurz greifende Fragestellung bzw. die Eingrenzung des Problems aus Tabellen und Daten. Letztendlich wird in vielen Fällen nicht nur die Datenbank, also das Schema und die Daten, umgestellt, sondern auch wesentliche Teile der Applikation und des Betriebs. Wir wollen an dieser Stelle einmal ein paar Fallstricke betrachten.

DAS KANN DOCH NICHT SO SCHWER SEIN, ODER?

Die Probleme liegen, wie bereits angedeutet, nicht in der eigentlichen Datenhaltung. Natürlich sind hier auch viele Dinge zu beachten:

Welche Objekte unterstützt das Zielsystem im Vergleich zur Quelldatenbank? Fehlen Typen (z.B. Synonyme, bestimmte Index-Arten, …)? Gibt es Workarounds?
Welche Datentypen können ggfs. nicht 1:1 übertragen werden?
Wie lange dauert die Migration bei einer großen Datenmenge? Welche Downtime ist akzeptabel?
Welche Migrationsaufwände entstehen (z.B. durch Anpassungen am SQL; jedes DB-Produkt hat eigene Spezialitäten, die über den SQL-Standard hinausgehen)?
….

Auf viele dieser und ähnlicher Fragen gibt es oftmals relativ einfache Antworten. Gerade die Cloud-Anbieter bieten hier (teilweise kostenfreie) Tools an, die solche Aufgaben erleichtern oder sogar teilweise komplett automatisieren können (z.B. AWS Schema Conversion Tool). Natürlich gibt es aber auch klassische Softwareprodukte (auch Open Source; lesen Sie dazu unseren Blogbeitrag Wurzeln schlagen oder Brücken bauen? Wie migriere ich meine Oracle Datenbank nach PostgreSQL).

Also doch kein Problem?
Die Wahrheit bzw. das Problem liegt im Code!

Wo liegen dann die eigentlichen Probleme? Ein Problem entsteht dadurch, dass Datenbanken eben nicht nur Daten, sondern oft auch Teile der Applikation beinhalten.

Klassische Objekttypen, die dieses Problem repräsentieren, sind Funktionen, Prozeduren und/oder Packages (geschrieben z.B. in Oracle PL/SQL oder Java, Python, …). Hier versagen viele Migrationsassistenten sehr schnell.

Daher muss im Vorfeld sehr sorgsam geprüft werden, welche Routinen migriert und welche Teile neu entwickelt werden müssen (in der Ziel-Datenbank oder in der Applikation). Natürlich müssen solche Änderungen auch entsprechend getestet werden. Hier können sehr schnell hunderte Personentage an Aufwand entstehen, die eigentlich nichts mit der Migration der Datenstrukturen zu tun haben.

WER SPRICHT HIER EIGENTLICH MIT WEM?

Treiber und Interfaces sind ein anderes Problemfeld. Häufig fehlt bereits die Transparenz, welche Systeme bzw. welche Applikationskomponenten und Schnittstellen überhaupt auf die Datenbank zugreifen. Oftmals gibt es nämlich nicht die (eine) Applikation, die nur von einem Server aus auf die Datenbank zugreift.

In einem Worst-Case-Szenario greifen unterschiedliche User mit unterschiedlichen Treiberversionen und -typen (JDBC, ODBC, .NET, …) von unterschiedlichen Systemen auf eine Datenbank zu. Ggf. sind diese Treiber sogar Teil einer Applikation (einkompiliert) und sind nicht direkt zu analysieren. Hier ist im Vorfeld zu klären, ob diese oder ähnliche Treiber auch für das Zielsystem zur Verfügung stehen oder ob es Alternativen gibt, die eine ähnliche Funktionalität bereitstellen, die von der Applikation erwartet wird (nicht alle Treiber haben die gleichen Funktionalitäten oder Einstellungen; Umgang mit Nomenklatur, Transaktionshandling, Exception Management, …).

Sollte für das Zielsystem kein äquivalentes Produkt verfügbar sein, sind ggfs. auch hier wieder Änderungen an der Applikation notwendig.

DAS WIRD MAN DOCH WOHL REGELN KÖNNEN?

Weitere Aufwände entstehen zudem häufig aus der Situation heraus, dass als Zielsystem ein neues, für den Betrieb noch relativ unbekanntes Produkt gewählt wird. Hier fehlen oftmals regulatorische und operative Erfahrungen bzw. Lösungen.

Während man voll auf die Migration der ersten Datenbanken und auf andere technische Probleme (Code und Treiber) fixiert ist, gehen die ersten Piloten in den Betrieb. Und genau da treten nun die ersten Probleme auf:

Kann die neue DB eigentlich auditiert werden und entspricht die Lösung den regulatorischen Standards?
Wie sieht es mit der Möglichkeit der Verschlüsselung („in motion" und „at rest") in diesem Punkt aus?
Können auch hochkritische Systeme migriert werden, bzw. Systeme weiter betrieben werden, die nach der Migration durch veränderte regulatorische Anforderungen oder Anwendungsänderungen kritisch geworden sind?
- Backup und Recovery: RTO und RPO werden auf einmal kritisch! Kann unsere neue Open-Source-Datenbank das?
- Security: Ein Single-Sign-on auf Basis von Kerberos und AD muss spontan doch möglich sein.
- Auditing: Eine Anbindung an das Produkt XYZ ist nun doch notwendig.
- …
…

Diese Aufgaben sind dann häufig neben dem Projekt zusätzlich zu stemmen, bremsen den Projektfortschritt und gefährden den Business Case.

WAR DOCH KLAR, DASS DAS NICHTS WIRD!
DIE WAHRHEIT LIEGT NOCH IMMER IM CODE!

Parallel zu den laufenden Aufgaben und Problemen treten dann mit aller Wahrscheinlichkeit auch noch zusätzlich Performance-Probleme auf. Während auf den Testinstanzen die Reports in erträglicher Zeit liefen, klemmt es „auf einmal" in der Produktion, da hier andere Spielregeln (mehr Daten? mehr User?) gelten.

Und natürlich haben unterschiedliche Datenbankprodukte andere Strategien (z.B. Ausführungspläne, Indizes, ….) wie SQL-Kommandos verarbeitet werden. Oftmals fehlt zu diesem Zeitpunkt aber das Expertenwissen – der Inhouse-Tuning-Experte, der auf dem Alt-System immer helfen konnte. Die Stimmung bei den Applikationsverantwortlichen, Entwicklern und eventuell auch bei den DBAs kippt und man sehnt sich nach der alten „Komfortzone".

UND WAS SAGT DIE STATISTIK DAZU?

Bei vielen Kunden lassen sich schnell Systeme identifizieren, die sich aufgrund ihrer Datenstruktur und Inhalte (also Tabellen und Daten) relativ einfach migrieren lassen. Zusätzlich lässt sich unkompliziert prüfen, ob es Code (z.B. PL/SQL) in der Datenbank (bzw. dem entsprechenden Applikationsschema) gibt und ob dieser Code ebenfalls migriert werden kann (z.B. von Oracle nach MariaDB; lesen Sie dazu unseren Blog-Artikel PL/SQL in MariaDB: Lost in translation?). Aus diesen Systemen sollten dann unkritische Systeme (geringe SLAs) gewählt und im Rahmen eines POCs migriert werden („Low-hanging Fruits"), um erste operative und auch Migrationserfahrungen (sofern noch nicht vorhanden) zu sammeln.

Oftmals zählen zu diesen Systemen Standardapplikationen, die von Hause aus auf mehreren Datenbankprodukten laufen würden und von daher relativ einfach zu migrieren sind. Parallel dazu (noch besser im Vorfeld) sollten alle anderen Stakeholder (Entwickler, Kunden, Softwarelieferanten) abgeholt und an das neue System „gewöhnt" werden. Nach und nach können weitere kritischere, größere DBs überführt werden.

WER HAT DENN GESAGT, DASS ES „NUR" EINFACH WIRD.

Datenbankmigrationen sind möglich und ergeben häufig Sinn, oft auch betriebswirtschaftlich. In vielen Fällen sind sie jedoch vor allem strategisch zu betrachten, um z.B. einem Vendor Lock-in zu entkommen. Von daher ist es schwierig, solche komplexen Projekte ad hoc aus einem Kostendruck heraus zu 100% umzusetzen (wir lösen das Alt-System innerhalb eines halben Jahres sofort komplett ab).

Die Enttäuschung ist hier meist vorprogrammiert. Eine solche Entscheidung sollte penibel vorbereitet und betrachtet werden, da es kein reines datenbanktechnisches Problem ist. Neben den DBAs sind hier unzählige weitere Personen und Gruppen zu berücksichtigen:

Das Management (auch als Support & Treiber des strategischen Gedankens)
Der Einkauf (Wie verhält sich der Alt-Hersteller? Rabatte werden gekürzt, Preise erhöht?)
Die Entwickler (sie sind entscheidend für die Akzeptanz des Produktes beim Kunden)
Die Sicherheitsbeauftragten (erfüllt das Produkt alle Anforderungen)
Zentrale (Infrastruktur-)Teams (Backup? Storage? OS?)

Sie haben Fragen rund um das Thema Datenmigration? Sprechen Sie mit uns. Wir beraten Sie immer herstellerneutral und das seit 30 Jahren.

Hier finden Sie die direkten Ansprechpartner.

{loadmoduleid 179}