Andere Datenbank
Gleiche Struktur, neues System.
Tabellen, Schlüssel und Daten ziehen um, die Typen werden übersetzt. Das ist der Fall, den diese Seite zeigt.
Konvertiert werden muss in jedem Fall: Typen übersetzen, Daten bereinigen, Werte umrechnen, die es im Ziel so nicht gibt. Die meiste Zeit kostet aber das Zusammenspiel. Es sind Hunderte Tabellen statt einer Handvoll, die Reihenfolge ergibt sich aus den Fremdschlüsseln, nach jeder Stufe wird geprüft, das Zeitfenster ist begrenzt, und um vier Uhr morgens gibt es ein paar rote Tabellen, die man ohne die anderen wiederholen will.
JOX deckt beides ab. Die Datenmanipulationen der Konvertierung laufen als SQL- und OS-Schritte in JOX, nachvollziehbar, mit Ausgabe und einzeln wiederholbar. Außerdem führt JOX alle Schritte in der richtigen Reihenfolge aus, so parallel, wie Ihre Datenbanken es vertragen, prüft nach jeder Stufe und wiederholt gezielt die gescheiterten Schritte. Diese Seite zeigt das an einem vollständigen Fall.
Bei manchen Migrationen bleibt die Struktur gleich und nur die Datenbank wechselt, bei anderen ist das Ziel eine völlig andere Struktur. Häufig ist es auch eine neue Version der eigenen Anwendung mit ein paar geänderten Tabellen und Spalten.
Tabellen, Schlüssel und Daten ziehen um, die Typen werden übersetzt. Das ist der Fall, den diese Seite zeigt.
Tabellen werden zusammengeführt oder aufgeteilt, Werte umgeschlüsselt, Stammdaten bereinigt. Jede dieser Umformungen ist ein eigener Schritt mit eigener Prüfung und lässt sich wiederholen.
Ein paar neue Spalten, eine geteilte Tabelle, geänderte Schlüssel: Der Umstieg auf die neue Version ist eine kleine Migration mit denselben Anforderungen an Reihenfolge, Prüfung und Wiederholbarkeit.
In allen drei Fällen wird die Migration in JOX zu einem wiederholbaren, deterministischen Prozess. Sie läuft so parallel, wie Ihre Systeme es tragen, und bei jedem Durchgang mit denselben Schritten in derselben Reihenfolge. Die Ergebnisse sind jederzeit nachvollziehbar: Jeder Schritt hat Status und Ausgabe, jede Tabelle ihren Abgleich.
Das Schema wurde eigens für die Demo erzeugt. Es ist so groß, dass niemand die Schritte von Hand schreiben will, und enthält die Fallen, an denen echte Migrationen scheitern.
Stammdaten, Organisation, Kunden und Kontakte, Vertrieb, Produkte, Aufträge, Rechnungen, Verträge, Service, Marketing, Aktivitäten. Dazu kommen Auto-Increment, Views und Grants an zwei Rollen, also die Objekte, die man leicht vergisst.
Eine Gutschriftsposition hängt über Gutschrift, Rechnung, Auftrag und Kunde bis an die Stammdaten. Die Reihenfolge wird aus dem Schema abgeleitet und nicht in einer Liste gepflegt.
Gut die Hälfte der Tabellen ist klein, der Rest reicht bis 700.000 Zeilen, vier Bewegungstabellen sind nach Monat partitioniert. Für jede Größenklasse gibt es einen eigenen Ladeweg.
Die Migration steht in JOX als Gruppe mit einigen hundert Job-Templates; jede Tabelle hat ihre eigenen Jobs und Abhängigkeiten. Jeder Lauf ist eine Order dieser Gruppe, und der zehnte Lauf macht nicht mehr Aufwand als der erste.
Geprüft wird, ob das Exportverzeichnis existiert und das Ziel es lesen kann, ob die Partitionen noch den geplanten entsprechen und ob es die Rollen gibt, an die gegrantet wird. Reste eines früheren Laufs werden aus dem Ziel geräumt. Schlägt eine Prüfung fehl, startet nichts.
Kleine Tabellen gehen in einem Job direkt von Quelle zu Ziel.
Große werden entladen und mit COPY geladen.
Die Datei wird direkt dort erzeugt, wo das Ziel sie liest.
Partitionierte Tabellen bekommen dieses Paar je Partition.
Der Fremdschlüssel von Auftrag auf Kunde wartet nur auf diese beiden Tabellen und nicht auf „alle Daten“. Danach folgen Sequenzen mit dem richtigen Startwert, Views und Grants.
Zeilenzahl und Prüfsumme beider Seiten werden je Tabelle und je Lauf in einer Kontrolltabelle im Ziel abgelegt. Ein SQL-Check wertet sie aus und meldet grün oder rot, mit Ausgabe und wiederholbar.
Die Schritte stehen in Subgruppen: Vorprüfung, Aufräumen, Tabellen anlegen, Bewegen, Nacharbeiten, Abgleich. Ein Lauf lässt sich auf einen Teil beschränken, einzelne Jobs lassen sich wiederholen, die Order lässt sich anhalten.
Das abschließende Aufräumen läuft erst nach einer manuellen Freigabe. Nach dem Lauf zeigt die Order-Map den kritischen Pfad, also welche Tabelle die Laufzeit bestimmt hat und warum.
Eine Migration ist ein komplizierter Vorgang, und je öfter sie geprobt wurde, desto besser geht sie aus. Man plant deshalb viele Durchgänge ein und nicht nur eine Probe vor dem Ernstfall. Da jeder Durchgang eine Order ist, ist das in JOX der Normalfall und erfordert keinen Umbau.
Die Migrationsgruppe in der Demo hat niemand von Hand angelegt. Sie wird von einem Planer erzeugt, einem eigenen Werkzeug, mit dem wir Migrationsprojekte vorbereiten. Er liest das Data Dictionary der Quelle, ordnet die Tabellen nach Fremdschlüsseln und Größe, wählt je Tabelle den Weg und schreibt das Ergebnis als Gruppe, die JOX importiert.
Der Planer selbst ist nicht Teil der Demo; wir bringen ihn in ein Projekt mit. Für Ihr Schema braucht er weder Daten noch Zugang, nur das Ergebnis eines Leseskripts über Ihr Dictionary. Daraus erstellen wir bei uns Ihren Plan.
Nach diesem Muster haben wir über Jahre Migrationen gefahren: Ein Analysewerkzeug plant, JOX führt aus. Die Demo zeigt also ein Verfahren, das sich in der Praxis bewährt hat.
Typen zu übersetzen und Daten zu bewegen ist lösbar. Schwierig wird es bei der Bedeutung der Daten, und dort entscheidet sich auch, ob eine Migration gelingt.
Eine Spalte im Altsystem bedeutet oft etwas anderes, als ihr Name sagt, und im neuen Modell gibt es sie in dieser Form nicht mehr. Die Zuordnung von alt zu neu ist eine fachliche Entscheidung.
Für Status, Produkte, Tarife und Kategorien muss festgelegt werden, was aus jedem alten Wert im neuen System wird. Diese Regeln entstehen im Projekt und ändern sich unterwegs. Nach jeder Änderung müssen sie erneut über alle Daten laufen.
Dubletten, unvollständige Sätze, Werte, die es nach den Regeln gar nicht geben dürfte. Was bereinigt, übernommen oder abgelehnt wird, entscheidet die Fachseite und nicht das Ladeprogramm.
Offene Aufträge, laufende Verträge, Rechnungen mitten im Zyklus: Sie müssen im neuen System mit ihrer Historie ohne Bruch weiterlaufen.
Dafür reicht „es lief durch“ nicht. Die Fachseite muss sehen können, was mit jedem Datensatz geschehen ist und warum. Abgleiche, Berichte und Ausgaben jedes Schritts machen das Ergebnis prüfbar.
Weil die Fragen fachlich sind, kommen die Antworten nach und nach. Lässt sich die Migration jederzeit vollständig und gleich wiederholen, ist jede Klärung ein kurzer Schritt und kein neues Projekt.
Dafür bringen wir neben JOX unsere Erfahrung mit. Wir begleiten die fachliche Klärung und setzen jede Entscheidung als nachvollziehbaren Schritt im Ablauf um. Technische Eigenheiten der Datenbanken wie Typen, Datumswerte und Schlüssel erledigt der Ablauf nebenbei; im Demo-Lauf sind sie als eigene Schritte zu sehen.
Wir haben Datenbank-Migrationen in vielen Konstellationen durchgeführt: zwischen unterschiedlichen Systemen, auf neue Strukturen und auf neue Versionen von Anwendungen. Die entscheidenden Fragen waren dabei fast immer fachlich: was die Daten bedeuten, nach welchen Regeln sie ins neue System übergehen und wie die Fachseite das Ergebnis abnehmen kann.
JOX steuert Migrationen zwischen allen Datenbanken, die es anbindet: Oracle, PostgreSQL, MariaDB und MySQL, DB2, Informix, Snowflake und weitere. Ablauf, Prüfungen und Stufen bleiben gleich; anders sind nur die Abfragen auf das Dictionary und das Entladeformat. Schreiben Sie uns, welche Systeme Sie einsetzen.
Nach der Registrierung bekommen Sie eine eigene JOX-Umgebung mit diesem Fall: Quelle, Ziel und die Migrationsgruppe, bereit für die erste Order. Sie können uns auch direkt von Ihrer Migration erzählen.