Thailand ...ein Daueraufenthalt

Entries tagged [java]

Datenbank Migration - Informix nach Mysql und vice versa

by Kun Pho


Posted on Sonntag Februar 27, 2022 at 07:00nachm. in Technik Programmierung


Von einem älteren Warenwirtschaftssystem auf einem Informix Dynamic Server, sollen die Daten auf einen neuen Web-Server übertragen werden. Zum Zeitpunkt der Migration stehen beide Datenbank-Server auf verschiedenen Maschinen online zur Verfügung. Nach der Migration wird der WWS-Server abgeschaltet und der Web-Server wird für alle Applikationen und Benutzer der Produktions-Server. Der Web-Server ist mit einem Mysql-DBMS aus gestattet, das bereits produktiv mit einem Servlet-Container kommuniziert und Web-Anwendungen dafür bereitstellt. Der Ist-Zustand:


  •     IBM Informix Dynamic Server Version 12.10.UC2IE

  •     Mysql Community-Server 8.0.28

  •     Servlet-Container Tomcat 9.0.58-Server

  •     Zu migrierende Daten: 19 Tabellen mit ca. 10000 Datensätzen.  

  •     Die Datenbank besteht nur aus Tabellen. Es gibt also keine Views, Trigger, Proceduren und der Gleichen.

Der Migrationsbestand ist gering und die Aufgabe könnte in rekordverdächtiger Zeit über die Bühne gehen.

1. Manuelle Vorarbeit (Informix)

Zunächst erstellen wir das Datenbankschema der Datenbank auf dem Informix-Server und bearbeiten dieses:




dbschema -t all -d warenwirtschaft wws.sql






Wenn wir schonmal auf dem Server sind, checken wir gleich die Datenmenge




Am schnellsten lässt sich der Schemen-File in einem Texteditor bearbeiten, der über die Option „Suchen und Ersetzen“ verfügt. Man kann das natürlich auch mit dem Stream Editor SED bewerkstelligen und dann Script gesteuert durchlaufen lassen.

Die folgenden Datentypen kennt Mysql u.a. nicht (links die Informix-Typen):



  •     serial                                →  long

  •     smallfloat                           → float

  •     smallint                              → int

  •     datetime year to fraction(3)  → datetime


Weitere Schritte:



  •     Alle Tabellen-Statistiken entfernen, das sind die Zeilen in den geschweiften Klammern {}

  •     Alle Zeilen mit revoke command an den Mysql Syntax anpassen.


2. Manuelle Vorarbeit (Mysql)




  •      Eine leere Datenbank mit gleicher Kollation erstellen. Hierzu den passenden Benutzer erzeugen und ihn mit den Berechtigungen ausstatten.

  •      Ein allgemeiner Tip: Immer für alle Datenbanken UTF-8 verwenden.

  •      Den angepassten Schemen-File als SQL in die Mysql laden und ausführen.

Zeit bis hierhin: ca. xx Minuten

3. Manuelle Vorarbeit (Beide)



Hier ist etwas Programmierarbeit erforderlich. Datenbanken lassen sich am einfachsten mit Java bearbeiten.

Kleines Java-Consolen-Projekt erstellen – JDBC im Buildpath eintragen.



  • Datasource-Factory-Klasse für 2 DBMS programmieren

  • Model-Klassen für jede Tabelle erzeugen.

  • DAO-Interfaces und Impl-Klassen für jede Tabelle erzeugen.

  • In einer Schleife eine Liste der Model-Objects aus der Quelle erzeugen

  • Die Models-Objects dieser Liste in die Datenbank des Ziels schreiben.


Zeit bis hierhin: ca. xx Minuten + yy Minuten


4. Migration

Unser Java-Projekt starten und das Ergebnis prüfen. Die Zeit hierfür ist stark von den Leistungsfaktoren der eingesetzten Rechner und der Infrastruktur abhängig. Hier hat es ca. 5 Minuten gedauert, bis die Daten durchgelaufen sind und das Ergebnis geprüft war.

Zeit insgesamt zz Minuten


Die Details


Das ist Rekordverdächtig :-) Ich habe natürlich die 38 DAO-Klassen und die 19 Model-Klassen nicht selber programmiert. Wer es war, die Details des kleinen Java-Projekts und auch die Inhalte von x, y, z kommen später.


Die Punkte 1 und 2 sind reines administratives Handwerkszeug und ich könnte mir die Detail-Schritte hierzu eigentlich verkneifen. Der Vollständigkeit halber, ohne große Kommentare:

Das Datenbank-Schema abrufen und den Schema-File bearbeiten:


Ich benutze dazu Eclipse. Die Datentypen mit: Suchen und Ersetzen anpassen und die markierten Teile bearbeiten. In diesem speziellen Fall werden Revoke- und Statistik-Einträge gelöscht. Es ist in der Unix-Welt nicht unüblich einen System-Benutzer die Datenbankberechtigungen zu übertrage und in diesem Fall ergibt das Übernehmen jeglicher Properties gar keinen Sinn.





Schema Bearbeiten


Weiter geht es im Klartext. Datenbank und Benutzer:


mysql -u monty -p
CREATE DATABASE warenwirtschaft CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE USER 'wws'@'localhost' IDENTIFIED BY 'da_kommt_keiner_drauf';
GRANT ALL ON warenwirtschaft.* TO 'wws'@'localhost';
quit;

mysql -u wws -p
USE wws;
source wws.sql;
quit;



… und rein mit dem Schema-file 



Von aussen geht es auch:


mysql -u wws -p warenwirtschaft < wws.sql



– fertig!



Wir haben bisher die blanke Datenbank, Benutzer und Berechtigung. Die beste Eingangsbedingung für eine Migration ist:



Beide Datenbank-Server sind online.



Der wirklich interessante Teil der Migration kommt jetzt: Der Programmier-Part. Ich arbeite mit Java und der Javax-DataSource-Klasse, weil in dieser Architektur intern völlig egal ist, wer die Daten liefert. Ich muss nur die Schnittstelle dazu konfigurieren und eine Factory dazu erstellen. Das ist eigentlich schon alles an handwerklicher Programmierarbeit. Der Rest, der benötigt wird, wird von einer Software erstellt, die ich mal entwickelt habe, als mir in der Web-Entwicklung das ewige Eintippen von immer gleichen Mantras auf die Nüsse gegangen ist. Das Tool heißt DAO_GEN und es generiert nicht nur alle nötigen DAO-Klassen (Nomen est Omen), sondern es baut mir den vollständigen Projekt-Baum für Datenbank getriebene Maven-Spring-Projekte. Vollständig heißt vollständig, inklusiver der Views zum bearbeiten von Datenbanken. Ich komme in einem anderen Beitrag darauf zurück. DAO_GEN baut mir also den gesamten DAO-Zweig und die Models. Er ist schnell und macht keine Tip-Fehler. Für so einen Projekt-Baum braucht er 2-3 Sekunden. 


Da die wesentlichen Dinge dieses Projektes generischen Ursprungs sind wird glaube ich jedem klar, dass etwaige Source-Code-Downloads sinnlos sind.



Die DataSource-Konfiguration in der db.properties sieht so aus:

#mysql DB properties
MYSQL_DB_DRIVER_CLASS=com.mysql.jdbc.Driver
MYSQL_DB_URL=jdbc:mysql://x.x.x.x:3306/warenwirtschaft
MYSQL_DB_USERNAME=wws
MYSQL_DB_PASSWORD=ohlala


#informix DB Properties
INFORMIX_DB_DRIVER_CLASS=com.informix.jdbc.IfxDriver
INFORMIX_DB_HOST=x.x.x.x
INFORMIX_DB_PORT=100000
INFORMIX_DB_SERVER=MickyMouse
INFORMIX_DB_USER=wws   
INFORMIX_DB_PASSWORD=japadappaduh
INFORMIX_DB_DATABASE=warenwirtschaft

...und die passende Factory so:





Die Factory





Es ist also nichts Aufregendes, oder revolutionär Neues zu erkennen. Mit dem Rückgabe Object DataSource können die generierten DAOs sofort arbeiten, aus den generierten Models Listen erstellen und diese dann wieder aus der Liste abtrennen und in die Ziel-Datenbank ablegen. Das Ergebnis prüfen wir auf der Mysql gegen das Ergebnis (s.o.) von der Informix mit:



SELECT sum( table_rows)FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'warenwirtschaft';



Das war es dann - fertig. Ach so, da war noch was: xx=10, yy=30 und zz=05 - ich muss meine Stundensätze erhöhen :-)