NetDoc Server. DB Migration mit der. Oracle Migration Workbench. NetDoc Server-DB Migration. Dirk Thieslack

Transkript

1 NetDoc Server DB Migration mit der Oracle Migration Workbench Dirk Thieslack it-function gmbh & co. kg. möckernstrasse 67. D berlin tel: +49 (30) fax: +49 (30) dthieslack@itfunction.de ahepfner@itfunction.de >> 1

2 Agenda 0 Wer bin ich? 1 Die it-function gmbh & co kg 2 Der NetDoc Server 3 Die Datenbank hinter NetDoc 4 Die Aufgabe/ das Ziel 5 Die Migration 6 Die Probleme 7 Die Lehre >> 2

3 0) Wer bin ich? Mein Name ist Dirk Thieslack Studium zum Dipl.-Ing. der Nachrichtentechnik 1993 Eintritt in die IVU Traffic Technologies AG 1999 Eintritt in die Oracle Deutschland GmbH 2002 Eintritt in die DIN IT Service GmbH Seit Mai 2004 selbständig tätig mit einer starken Verbindung zu it-function >> 3

4 1) Die it-function gmbh & co kg Feb gegründet (drei Gründer) > 10 Jahre IT-Erfahrung Aktuell sechs Mitarbeiter Seit März 2004 Microsoft Certified Partner ORACLE: 2 ehemalige Oracle Consultants + 1 Oracle DBA >> 4

5 1) Leistungen & Produkte Leistungen Produkte ITIL Dokumenten management Oracle Mobile Datenerfassung Mobile Anwendungen Portale / Customer Relationship Management (CRM) Enterprise Application Integration (EAI) Consulting Mobile Datenerfassung Oracle / Microsoft.Net Technologie / Java >> 5

6 1) Die it-function gmbh & co kg Schwerpunkte: Beratung Strategisches IT-Management IT-Effektivität Asset-Management ITIL Softwareentwicklung Mobility-Lösungen (.NET/Java) Portale/CRM (MS SQL-Server/Oracle) Application Enterprise Integration (Microsoft/Oracle) Datenbankadministration Produkte Netzinfrastrukturdokumentation (Visio/NetDoc) Mobile Datenerfassung (Frageb. Anw./Lead Mgmt) >> 6

7 2) Der NetDoc Server >> 7

8 3) Die Datenbank hinter NetDoc Flache Tabellen Benamung 1:1 gemäß WMI Strukturen T/SQL Routinen für die Auswertung >> 8

9 4) Die Aufgabe/ das Ziel Heben der DB-Plattform von SQL-Server auf Oracle Übernahme der Tabellenstruktur und der Daten Übernahme aller Stored Procedures Übernahme der gesamten Prozesslogik Übernahme der Datentypen Ersparnis Etablierte Geschäftslogik muss nicht angepasst werden Verminderter QS Aufwand Das Rad zwei Mal erfinden ist nicht nötig Wunsch Produkt auf einer Plattform entwickeln, auf zwei Plattformen anbieten? >> 9

10 5) Die Migration Worauf ist zu achten? Welche Dokumente sollte man lesen? B10254_1.pdf Welches Wissen sollte ich haben? Kenntnisse über Datentypen beider DB-Systeme T/SQL und PL/SQL Kenntnisse Kenntnisse über die Logik der Applikation Einrichtung OMWB Einfaches Entpacken des OMWB-Archivs Anbindung an die DB (hier SQL Server 2000) SQL Server muss im gemischten Authentifizierungsmodus laufen Aktuelle ODBC-Treiber für Quell-DB müssen vorliegen (evtl. auch JDBC Treiber) >> 10

11 5) Die Migration Worauf ist zu achten? ONLINE versus OFFLINE Notwendigkeit zu OFFLINE war bei uns nicht gegeben. Bei Nicht-Zugriff auf Quell-Server OMWB kann Skripte generieren, die Daten und Struktur aus Quell-DB ziehen. bei großen Datenmengen Erzeugung von Log-Dateien muss bei den Zwischenschritten händisch abgestoßen werden Es gibt es die Möglichkeit, einen kompletten Migrationslauf als Ganzes durchzuführen. Logs Schreiben wird hier kompliziert. >> 11

12 5) Die Migration Worauf ist zu achten? SQL-Server muss im gemischten Modus für die Authentifizierung konfiguriert sein. Die Workbench meldet sich mit DB-User an. Datentyp-Konvertierung wird abgefragt z.b. SQL: datetime -> Ora: timestamp Deaktivierung von Triggern/Constraints in Ziel-DB Nur bei schrittweiser Durchführung der Migration möglich. Ziel-DB sollte leer sein Es sollte keine Testmigration auf der DB vorher gelaufen sein. Durch Aufbau von Rollen, Erzeugung von Usern etc. ist die Wahrscheinlichkeit hoch, auf Fehler zu laufen. >> 12

13 6) Die Probleme Abweichungen von Datentypen z.b. SQL: datetime (1/300 sec), ORA: date (1 sec) Auflösung -> timestamp SQL: text (->4000Zeichen), Ora: Varchar2 SQL: image, Ora: blob Übernahme von Usern Werden nicht namentlich übernommen Übernahme von Stored Procedures Fehler in der Übernahme des Codes. Auskommentieren von fraglichen Quellstücken Abschneiden von Objektnamen, danach fehlerhafte Verweise im Quellcode. Bsp: DasIstDieFunktionDieIchMirSchonImmerGewuenschtHabe -> DasIstDieFunktionDieIchMirSch1 DasIstDieFunktionDieIchMirSchonImmerWeggewueschtHabe -> DasIstDieFunktionDieIchMirSch2 >> 13

14 6) Die Probleme Fehler beim Anlegen von Usern -> immer in eine leere DB migrieren Funktionskonvertierungen über eigene Procedures Unterschiedliches Verhalten beider DB-Systeme Locking Geschachtelte Transaktionen! Regular Expressions RAISE bei Fehlerbehandlung Multiple Resultsets! Fetch Prev. Userdefined Datatypes Migration wird trotz schwerwiegender Fehler als erfolgreich deklariert. >> 14

15 7) Die Lehre Der wirkliche Aufwand kommt nach der Migration Immer in eine leere Ora-DB migrieren Es müssen gute Kenntnisse über das Ziel und das Quell- Datenbanksystem vorliegen Reine DB-Kenntnisse reichen nicht aus. Es müssen tiefgehende Kenntnisse über die Applikation vorliegen. bereits bei Entwicklung einer DB an eine spätere, mögliche Migration denken (in Dokumentation zur OMWB beschrieben) Eine gute Unterstützung mit noch einigen Kinderkrankheiten. >> 15

16 7) Die Lehre/Auswertung Heben der DB-Plattform von SQL-Server auf Oracle Übernahme der Tabellenstruktur und der Daten Übernahme aller Stored Procedures Übernahme der gesamten Prozesslogik Übernahme der Datentypen Ersparnis Etablierte Geschäftslogik muss nicht angepasst werden Verminderter QS Aufwand Das Rad zwei Mal erfinden ist nicht nötig Wunsch Produkt auf einer Plattform entwickeln, auf zwei Plattformen anbieten? >> 16

17 Vielen Dank für Ihre Aufmerksamkeit >> 17