Wer von seinem IMS- auf ein DB2-Datenbanksystem umstellen möchte, muß um die Sicherheit und Vollständigkeit seiner Daten nicht mehr fürchten. Werner Paulus* schildert in seinem Erfahrungsbericht, wie sich mit Hilfe einer IMS-DB2-Schnittstelle die "gleitende" Migration von einem Datenbanksystem zum anderen bewerkstelligen läßt.
Dieser Bericht soll zeigen, wie mit Hilfe entsprechener Werkzeuge die Migration zwischen einer konventionellen IMS-Datenbank und dem relationalen Datenbanksystem DB2 möglich wurde. Das folgende Verfahren ist vor allem für IBM-Anwender mit großen Realtime-Beständen interessant, die in der schwierigen Situation sind, die Umstellung von IMS auf DB2 so zu planen, daß bei einem Fallback ein Sicherheitsrisiko vermieden werden kann. Hierbei sind sowohl die Planer der Datenbank-Infrastruktur gefordert, wie auch die Verantwortlichen der Systementwicklung.
Seit der ersten DL/1-Installation sind umfangreiche Investitionen auf der Grundlage von IMS getätigt worden. Obwohl viele Daten- und Programmbestände aus diesem Bereich heute modernisiert oder ersetzt werden müßten, machen Portierungsprobleme schnelle Ersatzinvestitionen auf DB2-Basis oft unmöglich. Dennoch läßt der Siegeszug von DB2 heute kaum einen IMS-Anwender mehr unbeeindruckt; nur wenige IBM-Anwender werden sich mit dem Thema DB2-Migration noch nicht beschäftigt haben.
Der Übergang vom einen zum anderen System ist alles andere als trivial, da die Datenbanken sich in vielen Aspekten voneinander unterscheiden. Die geschätzten Kosten, von bis zu mehreren hundert Mannjahren bei Tausenden von IMS-Programmen, sind nur einer der abschreckenden Faktoren. Problematisch ist auch der Mangel an qualifizierten Mitarbeitern, die heute niemand aus dem Hut zaubern kann. Was also ist zu tun? Kann man die Anzahl der umzustellenden Programme einschränken? Ist nicht doch eine Automation möglich, die Manpower und Durchlaufzeit halbieren kann?
Herkömmliche Verfahren, die von einer batch-mäßigen Übertragung der IMS-Daten nach DB2 ausgehen, können den erforderlichen Grad an Sicherheit nicht bieten, da ein gleichzeitiger Zugriff auf IMS und DB2 nicht möglich ist. Die wiederholte Übertragung von Datenbeständen im Batch-Betrieb kann hier zur Existenzfrage werden, da durch eine lange Umstellungsphase die Synchronisierung der Bestände sehr teuer oder unmöglich werden kann.
Bei unserem Verfahren erfolgt eine Echtzeit-Übertragung über ein IMS-DB2-Interface. Beide Datenbanken werden synchron bedient. Die Schnittstelle wird automatisch in die Anwendungen eingebaut und steuert mit Programmparametern die aktuelle Datenbasis. Dadurch wird auch ein programmweiser Fallback möglich.
Der Fallback wird durch den Einsatz eines Softwareschalters erleichtert, der nach Behebung der Fehlerursache einfach wie. der in seine Ausgangsposition zurückgesetzt wird. Darüber hinaus bietet das zentrale Interface vielfältige Optimierungsmöglichkeiten durch die externe Steuerung von 110-Operationen.
Durch den automatischen Einbau der Schnittstelle in die Anwendungen können Programm- und Datenumstellung zeitlich völlig voneinander getrennt werden. Vor dem Aufwand einer einmaligen Umstellung braucht sich niemand zu fürchten, da die Migration gleitend, ohne Druck und mit maximaler Sicherheit erfolgen kann.
Einige Fallbeispiele verdeutlichen, in welchen Varianten Migrationsprobleme zwischen den Datenbanken auftauchen.
1. Die einmalige Migration. Eine alte IMS-Anwendung soll komplett durch eine DB2-Lösung ersetzt werden. Neue Funktionen stehen im Vordergrund. Der alte Datenbestand kann ganz oder teilweise zu einem beliebigen Zeitpunkt im Stapelbetrieb übernommen werden. Für eine Batch-Übernahme stehen diverse Utilities wie zum Beispiel Data Extract (DXT) von IBM zur Verfügung. Verfahren dieser Art sind hin. reichend bekannt.
2. Die kontinuierliche Migration. Wieder soll eine IMS-Anwendung durch eine DB2-Lösung ersetzt werden, doch eine einmalige Umstellung ist aus Sicherheitsgründen nicht möglich. Beide Systeme sollen deshalb für eine Zeit lang parallel nebeneinander laufen. Auch die Datenbestände müssen doppelt gehalten und je nach Umfeld zeitgleich oder zeitversetzt synchronisiert werden.
Genau hier lag der Schwerpunkt unseres Projektes. Mir ist weder eine Möglichkeit, noch ein Produkt bekannt. das eine synchrone Bedienung von IMS und DB2 aus den Anwendungsprogrammen heraus erlaubt und dabei alle erforderlichen Umsetzungen bewerkstelligt.
3. Parallellauf beider Systeme. Wichtigstes Ziel ist hier, daß die Anwendung möglichst unverändert weiterläuft. Der Wechsel der Filebasis ist vor allem technisch oder softwarestrategisch begründet. Im Vordergrund steht also primär der Schutz alter Anwendungen.
Es gibt bereits Werkzeuge, mit denen SQL in die alten IMS-Quellen implementiert werden kann. Doch diese Lösung ist nur dann einsetzbar, wenn die Datenbasis einmalig gewechselt werden kann.
Außer diesen drei Fällen gibt es noch die Möglichkeit, alte IMS-Anwendungen weiterhin auf der IMS-Datenbank laufen zu lassen, weil sie nur isoliert eingesetzt werden; sie stehen alleine und sollen nicht umgestellt werden. Die Anzahl dieser isolierten IMS-Anwendungen verringert sich im Laufe der Zeit zusehends.
Alle genannten Fälle führen zu einer kürzer- oder längerfristigen IMS-DB2-Koexistenz mit unterschiedlichen Migrationserfordernissen. Darüber hinaus gibt es mehrere Varianten, die im Vorfeld der Migrationsplanung nur schwer erkennbar sind.
Mehrere Datenbanksysteme zu haben, ist nicht das Problem und kann sogar erwünscht sein. Schwierigkeiten entstehen erst, wenn eine alte Anwendung plötzlich auf einer neuen Datenbank zur Verfügung stehen soll, oder wenn eine neue Anwendung auch die alte Datenbank bedienen muß.
Für unsere Problemstellung war klar, daß die alten Anwendungen beide DB-Systeme gleichzeitig bedienen mußte. Die Umstellung der Daten sollte schrittweise erfolgen und wiederholbar sein, da umfangreiche, zentrale Datenbestände betroffen waren. Den verschiedenen beteiligten Wartungsteams sollten Verwaltung und Koordination leichtgemacht werden. Daher war es wichtig, daß die Weiterentwicklung vor, während und nach der Parallelphase mit den gleichen Programmnamen und -versionen erfolgte.
Prototyp sollte Klarheit bringen
Indirekt bedeutete dies, daß nur eine automatische Programmumstellung in Frage kam, die von außen steuerbar und in allen Phasen wiederholbar sein mußte. Die Antwortzeiten durften nicht länger werden als bisher, da einige der betroffenen Message Processing Programs (MPP) im Kundenservice eingesetzt wurden. Außerdem mußten die Durchlaufzeiten berechenbar bleiben, da der Nachtbatch bereits sehr viel Zeit in Anspruch nahm, und das schnellere Summit-Modell von IBM noch immer auf sich warten läßt.
Die grundsätzlichen Voraussetzungen waren durch die Systemsoftware der IBM gegeben. Der sogenannte Two-Phase-Commit gestattet eine vollständige Synchronisierung beider Datenbanksysteme. Wenn Updates sowohl auf IMS als auch auf DB2 in einer Transaktion erfolgen sollen, muß gewährleistet sein, daß entweder alle oder gar keine Updates erfolgen. Dies war eine unumgängliche Grundvoraussetzung für unsere Lösung. Ein Prototyp sollte uns die erforderliche Erfahrung mit dieser Technik bringen und unsere Vorgehensweise absichern.
Ausgehend von der Annahme, daß vielleicht nur 10 Prozent aller IMS-Daten synchron übertragen werden müssen, wurden bestimmte MPPS, Batch Message Processings (BMP) und Batchprogramme bezüglich ihrer I/O-Operationen neutralisiert und mit einem SQL-I/O-Modul getestet. Die Erkenntnisse aus den Tests ermöglichten den Ausbau der SQL-I/O-Module zu einem I/O-System, das SQL- und DL/I-Befehle ausführte - sowohl einzeln als auch synchron. Die Realtime File Transparency (RFT) entstand.
Sourcecode-Umstellung in einem Umsetzungslauf
Erst durch den Einsatz der RFT und durch die Messung der I/O's und deren CPU-Belastungen wurden weitere wichtige Probleme klar. Zunächst war eine systematische Quellcodeanalyse erforderlich, mit dem Ziel, den I/O inhaltlich zu analysieren und bei Bedarf umzustellen. Deshalb entwickelten wir Werkzeuge, mit deren Hilfe eine automatische Behandlung des Quellcodes möglich wurde.
Am Ende genügte ein einziger Umsetzungslauf mit anschließender Kompilierung, um die Sourcecode-Umstellung zu erledigen, und ein Link der Anwendungsprogramme, um die RFT-Runtimemodule anzukoppeln. Dadurch hatte sich der Dispositionshorizont der geplanten IMS-DB2-Migration in dramatischer Weise erweitert.
Um die ursprünglichen Systemanforderungen schrittweise zu erweitern, ersetzten wir jetzt das statische Phasenmodell durch einen dynamischen Projektzyklus. Die letzte Version des Prototyps war somit auch das Endprodukt. Folgende Kurzbeschreibung der Einzelprozesse soll den gesamten Vorgang der Programmumstellung verdeutlichen.
- Der Quellcode der Cobol- und PL/1- Programme wird maschinell zerlegt um Metadaten über Objekte, Funktionen und Prozesse zu gewinnen. Der Automationsgrad dieses Vorgangs ist von der Anzahl der erkennbaren Muster abhängig und muß vor allem anfangs manuell unterstützt werden.
- Auf Basis der gewonnenen und ergänzten Metadaten werden die alten Programme maschinell restauriert, indem alle I/O-Operationen neutralisiert werden. Dies geschieht, indem die alten I/Os durch Kommentierungsmarken außer Kraft gesetzt werden und darüber hinaus durch den Einbau bestimmter Interfaceteile. Die Anwendung kann dann normal kompiliert werden. Ein SQL-Precompiling und ein DB2-Bind sind nicht erforderlich, da alle DL/1- und SQL-Operationen von der RFT abgedeckt werden.
- Da alle I/O-Operationen in Form von Metadaten vorliegen können sie einzeln mit einem Testdriver ausgetestet werden. Dazu wird aus den Metadaten ein DB2-Database-Request-Module (DBRM) und ein DB2-Plan erstellt. Alle Testergebnisse werden automatisch mit diversen Maßzahlen (Anzahl der Records, CPU-Verbrauch) zu Vergleichszwecken gespeichert.
- Nach erfolgreichen Einzeltests werden alle Anwendungen getestet, indem das gleiche Interface wie beim Einzeltest dazugelinkt wird. Die Statistikfunktion der RFT erlaubt eine maschinelle Analyse großer Testserien durch das Speichern aller Runtime-Parameter der Tests. Diese Parameter sind entscheidend für die Vergleichbarkeit der Tests.
Vier Schalterstellungen der RFT sind möglich
Der Einsatz der RFT ermöglicht eine völlige Trennung zwischen der Programm- und der Datenumstellung, da die Anwendungen auch nach dem Einbau der RFT mit Hilfe der RFT-Schalterstellung "IMS" weiter auf der IMS-Datenbank laufen können. Dies bedeutet, daß alle restaurierten Programme ihre Arbeit aufnehmen können, obwohl noch keine Datenumstellung erfolgt ist.
Eine ständige Laufzeit-Überwachung der I/Os bezüglich Kommandocodes, Mengen, Filebasis, Returncodes und kritischer Programmteile ist notwendig, um Antwort- und Durchlaufzeiten vorhersagen zu können. Sowohl die DL/1- als auch die SQL-Returncodes, inklusive der Indikator-Variablen, werden zentral abgehandelt und erlauben somit eine flexible Steuerung der Ausnahmebedingungen.
Alle Testaktivitäten werden von der RFT protokolliert, um später in Managementreports einzufließen. Ob ein Programm getuned oder ersetzt werden soll, wird dadurch oft zu einer rein betriebswirtschaftlichen Entscheidung.
Je intelligenter die Mustererkennungsverfahren sind, desto höher ist der Automationsgrad der Migration. Dies gilt vor allem für die Sourceanalyse, die Umsetzung von Record- in Set-I/Os und die Interfacegenerierung. Durch die externe Steuerung der Start-I/O-Operationen bietet die RFT vielfältige Möglichkeiten der gezielten Optimierung.
Auch bei synchroner Realtime-Verarbeitung muß vorher meistens ein Datenbestand geladen werden, um in beiden Datenbank-Systemen dieselben Daten zu haben. Dieser Vorgang kann durch eine Umstellungsplanung auf Basis der RFT einmalig bleiben. Alle anderen Schritte lassen sich durch die Zahlen aus der RFT-Statistik messen und somit terminieren.
Es sind zur Ausführungszeit des einzelnen Programms eine von vier Schalterstellungen der RFT möglich:
1. Ein alleiniger IMS-Zugriff findet statt, wenn alle Programme, aber noch nicht die Daten umgestellt sind;
2. Zunächst IMS-, dann DB2-Zugriff, wenn zum Beispiel während der Parallelphase ein synchroner I/O erfolgen muß. IMS ist hier immer noch das Hauptsystem.
3. Zunächst DB2-, dann IMS-Zugriff; aus Sicherheitsgründen werden immer noch IMS-Bestände gepflegt, obwohl DB2 bereits das führende System ist.
4. Alleiniger DB2-Zugriff, zum Beispiel nach der Parallelphase: IMS-Bestände werden nicht mehr mitgepflegt.
Quellprogramme können umgestellt werden
Die Laufzeitstatistiken der RFT erlauben auch nach der Migration eine Überwachung und Wartung auf Anwendungsebene. Weiterentwicklungen während einer langen Umstellungsphase dürfen nicht zur Wartung mehrere Versionen desselben Programms führen, und müssen deshalb anhand der alten Quelle möglich sein. Dies wird dadurch erreicht, daß die automatische Umstellung der Quellprogramme jederzeit wiederholbar ist, da die Metadaten, der Programme gespeichert bleiben.
Folgende Erfahrungen haben dazu beigetragen, daß unsere ursprünglichen Migrationspläne, die wir vor dem Einsatz der RFT entwickelt haben, im Papierkorb gelandet sind:
1. Während sich alle Random-I/Os relativ problemlos umsetzen ließen, erwiesen sich die
Start-I/Os als "trickreicher". Komplexe Queries zum Wiederaufsetzen in MPPS, und vor allem zahlreiche Optimierungsvarianten, machen sogar SQL-Freaks das Leben schwer. Ein zentrales SQL-Handling versteckt diese Komplexität und läßt allen Programmen Optimierungen zugute kommen.
2. Eine Optimierung ohne Meßverfahren ist zwecklos. Sollen die Meßergebnisse über einen gewissen Zeitraum verglichen werden, so müssen auch die Veränderungen während dieser Zeit berücksichtigt werden. Deshalb ist eine Konfigurationskontrolle ebenso unverzichtbar, wie eine professionelle Version-, Release- und Update-Politik. Viele Tests brauchen gar nicht erst anzulaufen, wenn sich eine Komponente im Gesamtsystem geändert hat, die Einfluß auf die zu messende Anwendung nimmt.
3. Einfache Batch-Update-Programme, die vorher nur mit Backup und Restore versorgt wurden, mußten aus reinen DBMS-Erfordernissen auf einmal restartfähig sein. Die RFT bietet eine gute Möglichkeit, die Unit of Work zentral zu realisieren und doch programmspezifisch zu steuern.
4. Selbst wenn in IMS und DB2 die gleichen Datenfelder gespeichert werden, müssen trotzdem aus rein technischen Gründen Felder transformiert werden, wie zum Beispiel bei Time Date, Timestamp, Decimal und so weiter. Die RFT kann Transformationen jeder Art zentral und optimiert durchführen.
5. Vielleicht eine der wichtigsten Erkenntnisse überhaupt war die Tatsache, daß mit der RFT-Software Meßverfahren möglich wurden, für die sonst eine Laborumgebung notwendig gewesen wäre. Durch die Synchronfunktion der RFT (IMS/DB2 oder DB2/IMS) konnten IMS-I/O und DB2-I/O unter den gleichen Bedingungen gemessen werden.
Die gemessenen Werte variierten zwar stark, blieben aber in Relation zueinander trotz unterschiedlicher Mengen oder CPU-Belastungen ziemlich konstant. Erst diese Messungsmöglichkeiten machten deutlich, wo genau die eigentlichen Optimierungsprobleme lagen. Nur wer exakt sagen kann, welche Programmteile welche Ressourcen brauchen, kann auch gezielt und kostengünstig optimieren.
6. Das Meßverfahren habe ich nach einem Dreiband-Billardsystem benannt, das ich 1977 in Atlanta/USA zur selben Zeit kennenlernte, als ich mein erstes DL/1-I/O-Modul schreiben konnte. Sowohl das Dreibandsystem als auch das IMS-DB2-Meßverfahren brauchen einen Base-Point zur Berechnung. Meßwerte der IMS-I/Os bilden die Basis für äquivalente SQL-Operationen, die synchron ausgeführt und gemessen werden. GU 1:1,2 bedeutet zum Beispiel, daß das SQL-Äquivalent eines GET Unique den CPU-Faktor 1,2 benötigt hat.
RFT-Statistik weist auf kritische Punkte hin
Zusammengefaßt läßt sich das Fazit ziehen: Selbst wenn es gelingt, eine IMS-Anwendung mit einem sehr hohen Automationsgrad so umzustellen, daß wahlweise entweder auf IMS oder auf DB2 oder synchron auf beide zugegriffen werden kann, wird der kritische Teil der Umstellung während der Parallelphase erst durch die Statistiken der RFT planbar und durchführbar.