Abstract: 2 Perspektiven auf Datenmigrationen

Transkript

1 Abstract: 2 Perspektiven auf Datenmigrationen Stephan Eichenlaub St.-Josef-Platz Koblenz 0261/ stephan@eichenlaub.net 21. September Allg. Rahmenbedingungen und Anforderungen Definition: Datenmigration ist die (beliebig komplexe) einmalige Abbildung vorliegender Daten aus Alt-Software in neue Datenstrukturen und in neue Datenhaltungssysteme. Definition: Ein Datenmigrationsprojekt umfaßt die Datenmigration und die zur Festlegung der Abbildungen notwendigen Prozesse (u.a. Analyse der alten und neuen Datenstrukturen, Expertenbefragung, Programmierung). Definition: Ein Datenmigrationswerkzeug unterstützt seine Benutzer in einem Datenmigrationsprojekt bei der Datenmigration. Für Datenmigration wird im weiteren Text kurz von Migration gesprochen. 2 Bing Bang Migration In einem zeitkritischen Migrationsprojekt werden die Daten nicht nach und nach von Hand umgesetzt, sondern idealerweise auf einmal, in minimierter Zeit. Dafür wird Migrationssoftware geschrieben, die anderen Rahmenbedingungen und Anforderungen unterliegt als normale Software. 1. Die Migration ist zugleich singulärer Meilenstein (das neue System kann erst nach vollständig erfolgter Migration starten) und mission critical: An einer fehlgeschlagenen Datenmigration scheitert das gesamte umgebende Projekt. 2. Die Quell- und Zielsysteme und deren Datenhaltungslogiken sind vorgegeben, wenn auch den Entwicklern anfangs nicht notwendigerweise bekannt. Wissen über Teilsysteme muß von Entwicklern und Administratoren zusammengetragen und zu Abbildungen destilliert werden. 3. Die Spezifikation einer Migration ist oft das Ergebnis eines längeren Aushandlungsprozesses zwischen den Beteiligten, insb. dann, wenn zugleich mehrere umfangreiche alte Systeme mit divergierenden Datenhaltungsansätzen integriert werden. Gerade die Integration von Daten aus verschiedenen Quellen mit kontextabhängigen Prioritäten kann im Voraus kaum absehbare Komplikationen bringen. 1

2 4. Die Migrationssoftware muß auf Geschwindigkeit optimiert sein, um eine möglichst kurze Betriebsunterbrechung beim Wechsel von den alten Systemen zu den neuen zu gewährleisten. Idealerweise muß die Software in einer Nacht oder zumindest einem (verlängerten) Wochenende durchlaufen. 5. Sie muß einfach genug gehalten sein, so daß auch in letzter Sekunde noch Änderungen möglich sind, ohne zu unüberschaubaren Seiteneffekten zu führen. 6. Sie muß mit sehr großen Datenmengen umgehen können, es kommen Dateigrößen jenseits dessen vor, was normale Betriebssysteme (Windows NT, Unix) und die auf ihnen laufenden Programme handhaben können Migrationssoftware wird nicht von End-Usern benutzt, sondern ausschließlich von ihren Entwicklern, kommt demzufolge mit einer minimalen, kommandozeilenorientierten Oberfläche aus. 8. Sie muß nicht über einen längeren Zeitraum funktionieren in einer sich wandelnden Systemumgebung, sondern genau einmal, unmittelbar vor Echtstart des neu einzuführenden Systems. Damit ist sie quasi Wegwerf-Software, die nach einmal erfolgtem Einsatz nicht gewartet werden muß. 9. Es gibt es bereits während der Migration, spätestens aber mit Start des neuen Systems, einen Point of no Return, ab dem mit vertretbarem Aufwand nicht wieder neu aufgesetzt werden kann: Danach erkannte Fehler oder Probleme können nur noch bzw. müssen mit sehr hohem Aufwand repariert werden. 10. Bei zu erwartenden weiteren ähnlichen Migrationsprojekten sollte die Migrationssoftware so geschrieben sein, daß sie leicht zu adaptieren ist (hohe Reusability). 2.1 Projekt ERP-Migration Szenario: Bei der Einführng eines neuen ERP-Systems in einem mittelständischen Betrieb sollen die Daten aus den vorhandenen Software-Systemen übernommen werden. Zur Illustration einige Eckdaten aus einem realen Projekt: 1. Integration zweier alter in ein neues System: Die Daten eines PPS- und ein Fakturierungssystems wurden in ein umfassendes neues ERP-System migriert. 2. Über 100 zu migrierende Tabellen, mit jeweils bis zu über 100 Datenfeldern, vielfach 2 1-Migration/Integration. 3. unterschiedliche Standorte + Muttergesellschaft in USA Kommunikationsprobleme trotz fachlicher Kompetenz, persönlicher Sympathie und Zusammenarbeitswillen aller Beteiligten Änderungswünsche noch in letzter Minute. 4. Umfangreiche Umgebung: (a) Alte Systeme: HP3000, Cobol-Daten(bank)strukturen, Daten-Dumps. 1 Es gibt unter normalem Linux und den meisten UNIX-Derivaten außer cat kaum ein Systemprogramm, das Dateien größer als 2GB behandeln kann. In einem mir bekannten Projekt war ein Dump mit 45GB Größe zu handhaben. 2

3 (b) Extraktion mit Hilfe selbstgeschriebener Werkzeuge, z.t. nach händischer Analyse der HexDumps, da die separat gewartete Cobol-Dokumentation nicht immer mit der Realität übereinstimmte und echte Definitionsfiles nicht zur Verfügung standen. (c) Aufbereitung der Daten mit Hilfe von 4GL Rosi-SQL und ORACLE PL-SQL. (d) Betriebssysteme Windows-NT und Unix. 5. Verantwortung: Von der rechtzeitigen (u.a. Y2K-Problem) und erfolgreichen Migration hing der Gesamtprojekterfolg direkt ab. Vom Projekterfolg wiederum hing die Existenz des Kunden mit etwa 50 Arbeitsplätzen ab. 6. Migration, Support beim Echtstart und datenbankseitige Nachbetreuung nach Projektabschluß. 3 Explorative Migration Gänzlich andere Bedingungen bestehen für ein Migrationsprojekt im Bundesarchiv, bei dem Alt-Daten aus der DDR verfügbar gemacht werden sollen: 1. Die Quelldaten sind strukturell weitgehend unbekannt und zu erforschen. Sie sind physikalisch kopiert und liegen mittlerweile auf CD vor, stammen aber aus etwa 200 verschiedenen historischen EDV-Systemen (Lochkarten, Bänder, Dumps von ISAM-Dateien, DBase2, etc.). 2. Ziele: (a) Langzeitlagerung in einfach zugreifbarem, nicht-proprietärem Format (Konservierung) (b) Manipulation, Anonymisierung und Export in moderne Formate (SQL, XML, für Statistik-Pakete) 3. Die Zielstruktur ist nicht vorgegeben, sondern jeweils unter Beibehaltung semantischer Zusammenhänge aus der Quellstruktur abzuleiten. 4. Die Migration selbst ist Aufgabe von Historikern, der gesamte Erforschungs- und Aushandlungsprozeß nicht Gegenstand der Betrachtung. 5. Gefordert ist ein Werkzeug, daß von Historikern bedienbar ist und einfache Manipulations- und diverse Anonymisierungsmöglichkeiten bietet. Aus der Benutzergruppe leiten sich Anforderungen an Flexibilität, Verstehbarkeit, Bedienbarkeit und Wartbarkeit des Werkzeugs ab. 6. Demzufolge muß das Werkzeug Datenstrukturen migrieren können, die zum Zeitpunkt der Entwicklung noch unbekannt sind. Lediglich die verfügbaren Datentypen (numerisch, Strings) werden vorgegeben. 7. Migrationswerkzeuge können in einfachen Fällen regelbasiert generiert werden, wenn die alten und neuen Systeme verwandten Modellen folgen und das tun sie hier, da die neuen von den alten abhängen. Hierfür bietet sich die Entwicklung eines Migrationssystem-Generators an, der die Migrationssoftware für viele kleine Sub- Migrationsprojekte liefert. 3

4 4 Lösungsstrategien 4.1 Eigenschaften eines Migrationsprojekts 1. Kleines, eng kooperierendes Migrationsteam, das (wenn verfügbar) eng mit den Experten und Systemadministratoren der alten und neuen Systeme zusammenarbeitet. 2. Ein Rapid Prototyping Ansatz mit einer Reihe von Probemigrationen, die für alle Beteiligten die Konsequenzen der Migration erkenn- und diskutierbar werden lassen, ist zur Unterstützung des Aushandlungsprozesses anzuraten. Dabei nähert sich die Migrationssoftware iterativ von der ersten Probeversion in mehreren, gegen Ende zum Feintuning immer schneller aufeinanderfolgenden Schritten der Endversion an. 3. KISS-Prinzip: Keep It Simple, Stupid! Für jedes Problem wird die einfachstmögliche Lösung gesucht, denn die Systemumgebung ist komplex genug, sowohl in fachlicher wie organisatorischer Hinsicht. 4. Doppelte Teststrategie, sowohl syntaktisch durch Entwickler anhand der (sich fortentwickelnden) Spezifikation als auch semantisch durch Sysadmins und User. 4.2 Eigenschaften von Migrationssoftware 1. Extreme Modularisierung, sowohl horizontal (Phasen-Modell für Migrationsschritte) als auch vertikal (nach Daten arten und -herkunft) grundlegende Migrationsschritte: 1: Dump, 2: Analyse und Extraktion, 3: Normalisierung auf gemeinsames Zwischen-Format, 4: Laden in Migrations-Datenbank, 5: Verarbeitung, 6: Laden in Ziel-Datenbank 3. Jeweils maßgeschneiderte Werkzeuge für jeden Migrationsschritt, kein Rundumschlag. 4. Die Migration sollte weitgehend in der Zielumgebung durchgeführt werden. Dabei ist zu berücksichtigen, daß die Systemlast während der Migration um ein Vielfaches über der des Normalbetriebs liegt. 4.3 Eigenschaften eines Migrationssoftware-Generators 1. Definition des grundsätzlichen Vorgehens analog zur Migrationssoftware 2. Definition von Beschreibungssprachen (DDL, DML) 3. Entwicklung eines Generators für Software, die speziell für einen Datenkomplex die Migrationsschritte 2-5 durchführt 4.4 Benutzte Werkzeuge 1. Zur Datenanalyse (a) Editor und Hexeditor für große Datenmengen (b) MS Excel (c) C/C++ zur Daten-Extraktion 2. Zur Verarbeitung entsprechend der Zielumgebung der ERP-Migration: 4

5 (a) Oracle PL/SQL und 4GL ROSI-SQL 3. Für den Generator (a) GUI: Java-Servlets zur Generierung migrationsspezifischen HTML-Codes und zur Auswertung von Benutzereingaben, auf Basis von Apache Tomcat. Ansicht per Web-Browser. (b) Statische Funktionalität: Serverside PL/SQL. (c) Dynamische Funktionalität: Dynamic SQL. 5