zSeries Migrationskonzepte
Werbung
Donnerstag, 10. November 2005 11h00, Variohalle 6 Database zSeries Migrationskonzepte Thomas Niewel ORACLE Deutschland GmbH, München Schlüsselworte: Datenbanktechnologie, Migration 1. Einleitung Eine Vielzahl von operativen Systemen wird auf zSeries Mainframe-Systemen betrieben. Begründet durch die Historie von Mainframes basieren diese Anwendungssysteme auf Softwaretechnologien, die aus heutiger Sicht wenig flexibel und teuer zu betreiben sind. Aus diesem Grunde besteht in vielen Unternehmen der Wunsch diese Anwendungssysteme auf „moderne“ Plattformen zu portieren. Dieser Beitrag gibt eine Übersicht über Migrationskonzepte für DB2- und IMS-Datenbestände. Des Weiteren werden Szenarien beleuchtet, wie eine Migrationsstrategie von Anwendungssystemen gestaltet werden kann. Klassische Anwendungen in der zSeries Welt haben folgende Architektur: Abb. 1: Architektur von „klassischen“ z/OS Anwendungen In der Vergangenheit war die klassische Schnittstelle zu Anwendern eine 3270 Oberfläche. In einer solchen Umgebung wird das Transaktions-Management durch TP Monitore wie IMS/TM oder CICS/TS durchgeführt. In der Regel basiert die Datenhaltung auf folgenden Systemen: • DB2 for z/OS • IMS/DB , IDMS, ADABAS/C • File Systeme wie z.B. VSAM (in Einzelfällen) 2. Migration von DB2 for z/OS Datenbeständen DB2 for z/OS ist wie Oracle ein RDBMS. Aus diesem Grunde kann das Datenmodell problemlos in die Oracle Welt übernommen werden. Die Datentypen von DB2 for z/OS können bis auf wenige Ausnahmen in Oracle Datentypen überführt werden. Database DB-Entwicklung 18. Deutsche ORACLE-Anwenderkonferenz 2.1 Anlegen der Datenbankobjekte Die folgende Tabelle beschreibt die Konvertierungsregeln für DB2-Feldtypen, die in die Oracle Welt überführt werden sollen. DB2 Datentyp CHAR(N) VARCHAR(N) LONG VARCHAR(N) CHAR(N) FOR BIT DATA VARCHAR(N) FOR BIT DATA LONG VARCHAR(N) FOR BIT DATA DATE TIME TIMESTAMP GRAPHIC(N) VARGRAPHIC(N) LONG VARGRAPHIC(N) FLOAT(N) (single) FLOAT(N) (double) Decimal(P,S) INTEGER SMALLINT ROWID BLOB CLOB Oracle Datentyp CHAR(N) VARCHAR2(N) CLOB LONG VARCHAR2(N) CLOB LONG RAW(N) BLOB RAW(N) LONG RAW BLOB RAW(N) LONG RAW BLOB DATE CHAR(8) DATE TIMESTAMP(0) CHAR(2N+2) VARCHAR2(2N+2) VARCHAR(2N+2) FLOAT(21) FLOAT(53) NUMBER(P,S) NUMBER(10) NUMBER(5) RAW(40) BLOB CLOB Bemerkung N<=4000 N>4000 N>4000 N=<4000 N>4000 N>4000 1=<N=<2000 2000<=N<DB2 maximum long value 1=<N=<2000 2000<N=<DB2 maximum long value 1<=N<=21 22<=N<=53 Abb. 2: DB2 for z/OS und Oracle Datentypen 2.2 Migration der Datenbestände Die Migration von DB2 Datenbeständen kann mit folgendem Verfahren durchgeführt werden: 1. Entladen der DB2 Daten / Laden der Daten in die Oracle Welt 2. Datentransfer durch ein Oracle Transparent Gateway 2.2.1 Entladen/Laden der DB2 Daten Die DB2 Tabellen können durch das Programm DSNTIAUL entladen werden. Ab der Version 7 von DB2 for z/OS kann auch das DB2 Utility Unload verwendet werden. Das Programm DSNTIAUL erzeugt zwei Ausgabedateien • Loader Control Statements • Datendateien Es ist notwendig, die Loader Control Statements beim Transfer in ASCII zu konvertieren. Die von DSNTIAUL erzeugten Datenbestände müssen im Binärformat übertragen werden. 2.2.1.1 Loader Control Statements DSNTIAUL generiert Loader Control Statements im DB2-Loader Format. Diese Statements sind zu einem großen Teil Oracle-kompatibel; sie müssen jedoch angepasst werden. Das von DSNTIAUL generierte Load Control Statement muss um Oracle spezifische Zusatzinformationen erweitert werden: • Characterset • Satzlänge des von DSNTIAUL erzeugten Datenbestandes • Die Information, dass der Datenbestand von einer „Big Endian“ Maschine stammt Ein derart modifiziertes Load Statement hat folgendes Format: LOAD DATA CHARACTERSET D8EBCDIC273 byteorder big infile file location "FIX 59" REPLACE into TABLE tablename. Im nächsten Schritt ist es notwendig die Datentypen im Loader Control Statement anzupassen. Häufige Anpassungen sind: • Hinzufügen von Masken für Date und Timestamp Felder – DATE „DD.MM.YYYY“ (Installationsabhängig) – TIMESTAMP „YYYY-MM-DD.HH24.MI.SS.ff6“ • Nicht kompatible Datentypen (siehe Abbildung 2) sollten ebenfalls im Loader Script angepasst werden. VARCHAR Spalten, mit einer Länge von mehr als 4000 Bytes müssen im Oracle Loader Format VARCHARC geladen werden. Das Format VARCHARC besteht aus einer Längeninformation (bei einem Datentyp VARCHAR(32000) ist diese Längeninformation 5 Bytes) und dem Datenteil. Da das DB2 Utility DSNTIAUL diese Längeninformation nicht bereitstellt, muss DSNTIAUL die Daten mit Hilfe einer customized SQL Query entladen. 2.2.2 Datentransfer durch Transparent Gateways Die Oracle Transparent Gateways (Transparent Gateway for DB2, Transparent Gateway for DRDA) bieten die Möglichkeit, mit Hilfe von SQL auf DB2 Daten zuzugreifen. Die Konvertierung der Datentypen wird von den Oracle Transparent Gateways vorgenommen. Die Tabellen-Daten-Migration von DB2 nach Oracle kann mit Hilfe von SQL*PLUS wie folgt durchgefürt werden: o CREATE TABLE EMP AS SELECT * FROM SCOTT.EMP@DB2; o INSERT INTO EMP SELECT * FROM SCOTT.EMP@DB2; o COPY FROM SCOTT/TIGER@gateway INSERT EMP USING SELECT * FROM SCOTT.EMP@DB2; 2.3 Migration von 3GL Anwendungen 3GL Anwendungen nutzen in fast allen Fällen statisches SQL, um auf DB2 Datenbanken zuzugreifen. Die SQL Statements werden durch Nutzung des DB2 Precompilers(DSNHPHC) „kompiliert“. Durch einen Bind Prozess werden diese SQL Statements dann in der DB2 Datenbank gespeichert. Um mit 3GL Programmen auf Oracle Datenbanken zuzugreifen, ist es notwendig einen Oracle Precompiler zu nutzen. Dieser Precompiler ist für COBOL, PLI und Fortran verfügbar. Grundsätzlich ist der DB2-SQL-Dialekt „relativ“ verträglich mit dem Oracle-SQL-Dialekt. Je nach genutzen SQL Funktionalitäten sind kleinere Änderungen erforderlich. Bedingt durch das DB2 Locking- und Performance-Verhalten ist es notwendig DB2-SQL Erweiterungen zu entfernen. Beispiele für solche Optionen sind: • For Fetch Only • With UR (Isolation Overriding) In die allgemeinen Fehlerroutinen von DB2-Anwendungsprogrammen ist in der Regel das Programm DSNTIAR eingebunden. Um den Migrationsaufwand gering zu halten stellt Oracle eine eigene Version dieses Programmes zur Verfügung. 3 IMS/DB Datenbanken IMS/DB Datenbanken sind hierarchische Datenbanken, auf die mit Hilfe von DL/1 Calls zugegriffen wird. SQL wird als Abfragesprache für diese Datenbanken nicht standardmässig unterstützt. Database DB-Entwicklung 18. Deutsche ORACLE-Anwenderkonferenz 3.1 Überführen des IMS-Datenmodells in eine relationale Struktur Eine IMS/DB Datenbank besteht aus sogenannten Segmenten. Diese Segmente sind durch hierarchische Strukturen verbunden. Abb. 3: IMS/DB Datenbank mit Segmenten Kunde, Auftrag, Adresse, Mahnung und Lieferung Um solche abhängigen Segmente in ein relationales Oracle Schema zu überführen empfiehlt sich eine Überführung von IMS-Segmenten in relationale Tabellen (1 Segment = 1 Tabelle). Die IMS-Segment-Hierarchie kann in der relationalen Welt durch „Referential Integrity“ abgebildet werden. Beispiel einer IMS-Segmentbeschreibung: Abb. 4: IMS Definitionen (SEGMENT Makro) Die aus diesen Makro-Aufrufen abgeleitete Oracle-DDL sieht wie folgt aus: Abb. 5: Überführtes Datenmodell 3.2 Migration der Datenbestände Je nach Datenbankdesign können die Daten mit IMS Utilities(z.B. IMS Unload FABHURG1 oder 3rd Party Tools) entladen werden. Je nach Komplexität des Datenbankdesigns kann es aber auch notwendig sein, spezielle Entlade-Programme für IMS Datenbanken zu kodieren. Die beim Entladevorgang entstandenen sequentiellen Dateien können dann mit dem SQL*Loader in die Oracle Welt geladen werden. Es empfiehlt sich, Scripts für die Generierung der Oracle-Loader-ControlStatements zu nutzen. 3.2.1 Datentransfer durch das Transparent Gateway for iWay Das Oracle Transparent Gateway for iWay bietet die Möglichkeit, mit Hilfe von SQL auf IMS/DB Daten zuzugreifen. Die Konvertierung der Datentypen wird vom Oracle Transparent Gateway for iWay vorgenommen. Die IMS/DB Datenmigration kann wie bei den Transparent Gateways for DB2/DRDA mit Hilfe von SQL*PLUS durchgeführt werden. o CREATE TABLE EMP AS SELECT * FROM SCOTT.EMP@IMS; o INSERT INTO EMP SELECT * FROM SCOTT.EMP@IMS; o COPY FROM SCOTT/TIGER@IMS INSERT EMP USING SELECT * FROM SCOTT.EMP@IMS; Database DB-Entwicklung 18. Deutsche ORACLE-Anwenderkonferenz 3.3 Anwendungsprogramme Anwendungsprogramme, die auf IMS-Datenbestände zugreifen, nutzen DL/1-Aufrufe, die in 3GL-Programme eingebettet sind. Folgende DL/1-Funktionalitäten sind verfügbar, um auf IMS/DB-Datenbestände zuzugreifen Abb. 6: DL/1 Aufrufe Wie aus der Abbildung 6 ersichtlich, sind DL/1 Calls nicht mit SQL vergleichbar. Aus diesem Grunde müssen die DL/1 Aufrufe der bestehenden Anwendungen in entsprechende SQL Zugriffe umgewandelt werden. 4. Migrationsstrategien Klassische Hostumgebungen nutzen IMS/TM und CICS/TS als Transaktionsmonitor. Programme, die von einem Transaktions-Monitor aufgerufen werden, greifen in der Regel auf z/OS Datenbestände zu. Oracle bietet die Möglichkeit z/OS als Client Plattform für Oracle Datenbanken zu betreiben. Folgende z/OS Applikationen können plattformunabhängig auf Oracle Datenbanken zugreifen: • TSO Anwendungen • z/OS Batches • Anwendungen unter Unix System Services(USS) • IMS Anwendungen (durch „Oracle Access Manager for IMS“) • CICS/TS Anwendungen (durch „Oracle Access Manager for CICS“) Diese Möglichkeiten erlauben eine phasenweise Migration von z/OS Anwendungen, um Risiken zu begrenzen. Die erste Phase einer solchen Migration ist die Datenmigration in die Oracle Welt. Durch die Oracle Integrationsprodukte können die Anwendungen weiterhin unter z/OS betrieben werden. Die zweite Phase des Migrationsprojektes ist die Migration der Anwendungsysteme auf eine kostengünstigere Zielplattform. Kontaktadresse: Thomas Niewel ORACLE Deutschland GmbH Riesstr. 25 D-80992 München Telefon: Fax: E-Mail : Internet: +49(89)1430-1899 +49(89)1430-1572 [email protected] www.oracle.de
