Oracle to MySQL Migration

Oracle nach MySQL Migration
Gespeicherte Prozeduren, Packages,
Trigger, Scripte und Anwendungen
White Paper
März 2009, Ispirer Systems Ltd.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
Einführung
Der Zweck vom diesen White Paper ist Faktoren, die Datenbank-Migration von Oracle nach
MySQL beeinflußen, zu beschreiben. Kosten- und Risikoaspekten werden detailliert
werden, als auch Werkzeuge und Methoden, die eine Konvertierung von hoher Qualität
gewährleisten.
Das ist wahr, dass die Sun MySQL Datenbank drastisch Gesamtbetriebskosten (eng. Total
Cost of Ownership (TCO)) reduzieren kann durch Reduzierung der Kosten für Lizenzen,
Hardware und Verwaltung. Das höchste Risiko der Übertragung auf die MySQL Plattform
ist Schwierigkeiten bei der Migration der Geschäftslogik von Oracle, besonders wenn die
bestehende Anwendungen intensiv PL/SQL Prozeduren, Trigger, Packages und Oracle
spezifische SQL-Anweisungen in Oracle benutzen.
Die Migration von Oracle nach MySQL kann problematisch, zeitaufwändig und teuer sein.
Immerhin, nachgewiesene Methoden und Werkzeuge können drastisch Kosten einer
Migration und dafür gebrauchte Zeit reduzieren, als auch Risiken wesentlich beseitigen.
Mithilfe unseres Migrationsprodukts SQLWays kann die Migration bewertet, durchgedacht
und hoch-automatisiert werden. Ein richtiger Einsatz der automatisirten Werkzeuge und
leistungsstarke Projektsverwaltung am Ort gewährleisten Einsparungen um mehr als 70%
im Vergleich mit Verwendung von traditionellen manuellen Techniken der Migration.
Zusammen mit Einsparungen, die mit Benutzung von MySQL verbunden sind, gibt es
Kosteneinsparungen, die mit Benutzung des Werkzeugs für Migration SQLWays
verbunden sind. SQLWays ist ein attraktives Angebot für Migration.
Herausforderungen
Die Oracle-Datenbank bietet fortschrittliche Möglichkeiten für Entwicklung der
Geschäftslogik an, die sich ganz innerhalb der Datenbank befindet und PL/SQL
gespeicherte Prozeduren, Funktionen, Packages und Trigger benutzt.
Oracle PL/SQL ist eine wartbare und perfomante prozedurale Erweiterung von SQL, die von
Oracle dringend empfohlen wird, denn sie verbessert Leistungsfähigkeit. In meisten
Anwendungen führt die Benutzungvon PL/SQL normalerweise zu einer großen Anzahl
von Prozeduren, Packages und Trigger. Datenbank MySQL benutzt kein PL/SQL, obwohl
sie ähnliche Funktionalität hat.
Gemeinsam mit der spezifischen Syntax von Oracle bietet PL/SQL viele nicht-ANSI
kompatibele Merkmale an, einschließlich der Merkmale, die es nur in Oracle gibt. Diese
spezifische Merkmale sind:
• Packages - shared-Variablen in Packages, eingebettete Packages
• %TYPE, %ROWTYPE, Ausnahmen
• Objektorientierte Merkmale: Objekttypen, Funktionen, und Sammlungen
• Business intelligence und XML Merkmale usw.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
2
Migration von Oracle nach MySQL kann eine komplizierte Aufgabe sein, besonders
wenn spezifische Merkmale von Oracle benutzt werden, wie z.B. die vorstehend
beschriebene Merkmale.
Dennoch kann diese Migration relativ einfach und risikolos sein: z.B. wenn eine ZielDatenbank relativ wenige Tabellen hat und eine einfache Geschäftslogik hat.
Weil Kosten und Risiken können sich abhängig vom Projekt variieren, barucht man eine
vorläufige Bewertung.
Bewertung
Das Ziel von Bewertung ist die Größe, Machbarkeit, Kosten und Risiken einer DatenbankMigration von Oracle nach MySQL zu bestimmen.
Bewertung einer Datenbank
Erstens müssen Sie Typen der migrierten Datenbankobjekte und ihre Anzahl bestimmen.
Datenbankobjekte schließen die folgenden objekte ein:
•
•
•
•
•
•
•
Tabellen
Sichten
Pozeduren
Funktionen
Packages
Trigger
Sequenzen, Synonyme usw.
Wenn Sie den PL/SQL Code konvertieren müssen (Prozeduren, Packages, Funktionen und
Trigger) oder Sichten/Abfragen, die spezifische Oracle SQL-Syntax enthalten, müssen Sie
kennenlernen, welche Merkmale benutzt werden und wieviel Merkmale es gibt. Unter der
Charakteristika, die gezählt werden müssen, gibt es:
•
•
•
•
•
•
•
Nicht-ANSI kompatible SQL-Funktionen, Operatoren und Anweisungen
Resultsets
Cursor Loops
Ausnahmen
Temp-Tabellen
Objekttypen und Funktionen
Sammlungen
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
3
•
•
•
•
Dynamic SQL
Eingebettete Packages
OLAP-Funktionen
XML-Funktionen usw.
Nachdem Sie die Übersicht einer Datenbank beendet haben, wäre es besser, MySQLÄquivalente oder Lösungen zu wählen und spezifische Oracle-Funktionalität zu ersetzen.
Sie können typische Lösungen dafür in den folgenden Kapiteln finden.
Bewertung einer Anwendung
Gemeinsam mit Schema und Geschäftslogik auf der Serverseite kann es ebenfalls
notwendig sein, SQL-Anweisungen in den Anwendungen zu modifizieren. Das ist wichtig
auszuwerten, wieviel gemacht werden muss, um eine Migration durchzuführen.
Am Anfang müssen Sie checken, welche Datenbank-API, um auf die Oracle Datenbank
zuzugreifen, in Ihren Anwendungen benutzt wird. Das ist notwendig kennenzulernen, wie
viel Quelle-Dateien einer Anwendung der spezifische Oracle Code enthält, die endlich
modifiziert werden müssen mit MySQL zu arbeiten.
Meisten Anwendungen benutzen eine standardisierte API wie ODBC, JDBC, oder ADO.NET
auf Oracle zuzugreifen, aber einige Anwendungen können eine native API benutzen wie
Oracle OCI oder Pro*C/C++. Sammlung von dieser Information ist obligatorisch.
Sogar wenn Sie eine standisierte API benutzen, wie z.B. solche API, die ODBC/JDBC Treiber
verwenden, müssen bestehende SQL-Anweisungen auch verändert werden. Zum Bespiel,
DECODE-Funktionen oder hinterlassene Outer Join Syntax (*) muss modifiziert werden. Es
wird empfohlen, eine Anzahl von nativen SQL-Anweisungen zu bestimmen.
Wenn eine Anwendung eine native API benutzt, wie z.B. Oracle OCI, müssen Sie dann den
Code von Datenbank-Zugriff vollständig umbauen und MySQL API oder ODBC verwenden.
Werkzeuge für Bewertung
Das ist wichtig zu verstehen, wieviel Wert spezifische Merkmale einer Datenbank haben. Wie
kann man besser die Benutzung dieser Merkmale bewerten?
Erstens müssen Sie die Anzahl von Tabellen, Prozeduren, Sichten, usw. bestimmen,
wie es in der folgenden Tabelle gezeigt wird. Um eine ausführlichere Analyse
durchzuführen, können Sie das Produkt SQLWays von Ispirer benutzen, um
statistische Information zu erhalten.
Hier gibt es ein Muster der Bewertung:
Datenbank
Tabellen
Sichten
Prozeduren
Funktionen
Trigger
Packages
Anzahl
350
280
420
135
50
10
Datenbank-Details
BLOBs
Outer Joins
Ref Cursors
Erweiterungen
Temp-Tabellen
37
155
89
450
34
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
4
Anwendung
Java/JDBC
Outer Joins
SQL-Funktionen
Resultsets
590 files
190
356
47
Migration - Behandlung Automatisierte Konvertierung
Nachdem Sie Ergebnisse der Bewertung bekommen haben, können Sie einen Plan Ihrer
Migration machen. Wenn Sie nur einige dutzend Prozeduren haben, können Sie manuelle
Konvertierung durchführen, aber wenn Sie einige hundert oder tausend Prozeduren
haben, wäre es viel besser unter den automatisierten Werkzeuge für Migration etwas für
sich wählen. SQLWays bietet auch eine Lösung für Sie .
Kosten und Risiken
Kosten und Risiken einer Konvertierung hängen von der Größe des Projekts ab. Bitte
bemerken Sie, dass Kosten und Risiken auch von Komplizierheit und Frequenz der OracleMerkmale in einer Datenbank oder Anwendung beeinflusst werden. Je mehr OracleMerkamale es gibt, desto schwieriger und teuerer eine Konvertierung ist. Umso mehr, je
mehr Oracle-Merkmmale benutzt werden, desto mehr automatisierte Werkzeuge Ihnen
helfen werden, den Erfolg zu erreichen.
Kosten einer Migration von Daten und DDL
Migration von Daten und DDL (Schema) Objekte wird normalerweise problemlos
durchgeführt, denn es gibt viele Werkzeuge auf dem Markt, die Ihnen bei solcher
Migration helfen können.
Typische ;igration von Daten und DDL schließt Konvertierung der folgenden Objekte ein:
•
•
•
•
Datentypen
Beschränkungen (Primär-und Fremdschlüßel, unique-Beschränkungen,NULL,defaults,usw.)
Verlagerung von Daten
Indexe
Obwohl es Unterschiede in Syntax zwischen Oracle und MySQL DDL-Anweisungen gibt,
haben beide Datenbanken ähnliche Datentypen (Charakter, Anzahl, Datum, Zeit, LOBs),
und Sie können ähnliche Integrität-Beschränkungen spezifizieren.
Muster-Bewertung einer DDL-/Daten-Migration:
Datenbank
Tabellen
LOBs
Max. Reihen der Tabellen
Max. Größe der Tabellen
Migrationsprozess
Bewertung
MySQL Konfiguration
Automatisierte Übertragung
Teste, Veränderungen der
Konfigurationen, nächste Iterationen
Gesamtzeit
<100 tables
10 columns
<10M
<300 Mb
2-8 hrs
4-16 hrs
2-4 hrs
4-12 hrs
12-40 hrs
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
5
Werkzeuge
Gratis, oder weniger als $500
Dank der Automatisierung ist der Preis einer Migration von DDL und Daten nicht direkt
proportional zur Anzahl von Tabellen und Daten. Zum Beispiel, der Preis einer Migration
für 100 und für 300 Tabellen kann derselbe sein, wenn Tabellem ähnliche Struktur und
Größe von Daten haben.
Als die Anzahl von Tabellen und ihre Größe sich steigern, brauchen Sie mehr Zeit um eine
MySQL Datenbank richtig einzustellen, Verlagerung von Daten anzupassen und auf
verschiedene Aufgabe sich zu konzentrieren, z.B. auf Schaffen von Indexen.
Risiken bei der typischen Migration von DDL und Daten
Typische Migration von DDL/Daten wenige Risiken bringt. Mithilfe SQLWays kann man die
ganze Übertragung einer Datenbank im Evaluierungsmodus realisieren, Daten übersehen,
und Anwendungen benutzen, die mit der neuen MySQL Datenbank verbunden werden:
Das ist ein üblicher Arbeitsablauf:
1. Übertragung der ganzen Datenbank im Evaluierungsmode zu realisieren
2. Fehler der Übertragung, Strukturen der Tabellen, Anzahl von Reihen in Datenbanken zu
checken
3. Daten in allen repräsentativen Tabellen übersehen und prüfen mithilfe SQL-Werkzeuge
wie z.B. Oracle SQL*Plus, MySQL Query Browser oder MySQL Befehlszeilen-Programm.
4. Die mit MySQL verbundene Ziel-Anwendung ausführen und prüfen
Komplizierte Datenmigrationen
Obwohl Migration von Daten/DDL im Vergleich mit Migration der Geschäftslogik
insgesamt relativ enfach ist, gibt es einige Bedingungen, die Migration von Daten/DDL
erschweren können:
•
Große Volumen von Daten
Wenn Sie große Volumen von Daten migrieren müßen, dann müssen Sie sich mehr um
Konfiguration von MySQL Servern bemühen.
Große Volumen von Daten können den Migrationsprozess beeinflussen, besonders in Bezug
auf die für Migration gebrauchte Zeit. Um die Zeit für Migration zu reduzieren, können Sie
die Migration auf der mitlaufenden Weise durchführen. Dadurch steigert sich die
Kompliziertheit einer Migration.
Also, die Übertragung von großen Datenvolumen kann Fehlerbehandlung erschweren, denn
Sie können sich nicht erlauben, die ganze Migration noch einmal zu laufen, wenn nur einige
Tabellen falsch konvertiert wurden.
Der Projekt kann Vorteile aus der Benutzung von Werkzeugen ziehen, die BULK INSERT
Optionen haben, weil die Werkzeuge, die Ergebnisse nach der Konvertierung jeder Reihe
zeigen, nicht mehr für die Konvertierung von großen Volumen von Daten gültig sind.
• Minimale Ausfallzeit
In einigen missionskritischen Umgebungen müssen Sie die Ausfallzeit möglichst minimieren.
Um diesen Anfoderungen zu entsprechen, müssen Sie den Migrationsprozess ausführlich
durchdenken, um die Verlagerung von Daten gleichzeitig durchzuführen, oder statische
Tabellen aus dem Ausfallzeitsfenster zu übertragen. Manchmal müssen
Replikationswekzeuge benutzt werden, um die Ausfallzeit zu reduzieren.
Leistungsanforderungen
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
6
Einige Umgebungen stellen sehr strenge Anforderungen an Leistungsfähigkeit der
Anwendungen. Während einer Migration nach MySQL ist es obligatorisch, dass die
bestehende Leistungsfähigkeit behalten und verbessert werden muss. Deshalb müssen Sie
mehr Zeit auf Design und Anpassungen einer Datenbank verwenden, umso mehr, sie
müssen Prüfungsmigrationen realisieren, um die Leistungsfähigkeit, die Sie nach der
Migration haben werden, zu analysieren.
Risikominderung für komplizierte Migrationen von DDL und Daten
Komplizierte Datenmigrationen können mit einem einfachen Doppelklick nicht realisiert
werden. Die Proof-of-Concept Migration muss durchgeführt werden um allen
Anforderungen gerecht zu werden.
Gewöhnlich wird der folgende Migrationsprozess für komplizierte Datenmigrationen
empfohlen:
•
•
•
Proof-of-Concept Migration um Durchführbarkeit der Anforderungen zu checken
Prüfungsmigration um die ganze Produktionsmigration zu emulieren und allumfassende
Teste durchzuführen
Productionsmigration
Kosten einer Konvertierung von Geschäftslogik
Wenn Ihre Datenbank einige dutzend Prozeduren und Trigger enthält, ist es einfacher, sie
manuell nach MySQL SP Syntax überzuschreiben. Aber wenn Sie einige tausend
Prozeduren und Trigger haben, dann ist manuelle Konvertierung ziemlich teuer. Sie
könnten über ein automatisiertes Migrationswerkzeug nachdenken.
Der Preis einer manuellen Konvertierung ist direkt proportional zur Anzahl von
Codezeilen, die Sie konvertieren müssen.Andererseits können automatisierte Werkzeuge
den Preis begrenzen und Migration der mehreren Millionen von Codezeilen vernünftig in
Bezug auf Kosten und Aufwand machen.
Abhängig von konvertierten Codezeilen kann automatisierte Konvertierung der
Geschäftslogik mithilfe eines Werkzeugs wie z.B. SQLWays 7-10 mal weniger als eine
manuelle Konvertieung kosten.
Vielfalt und Häufigkeit von spezifischen Oracle Merkamalen bestimmen die Kompliziertheit
von Migration der Geschäftslogik und den Automatisierungsgrad, den Werkzeuge
gewährleisten können.
Nach der Meinung unserer Experten, für effektive Automatisierung muss ein
Migrationswerkzeug wie z.B. SQLWays bis zu 95% von Geschäftslogik konvertieren.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
7
Projektabschätzung einer Mustermigration der Geschäftslogik auf der Serverseite sieht so aus:
Datenbank
Gespeicherte Prozeduren
Trigger
Funktionen
Packages
1000
300
250
10 (50 Prozeduren per Package)
Manuelle Konvertierung 5,000 Stnd (~30 Männer-Monate)
Personalkosten
$50,000-$250,000 (abhängig
vom Land)
Automatisierte Konvertierung
Bewertung, Besprechungen
der Lösungen
16-40 Stunden
Iterative Konvertierung,
Analyse
Teste
40-80 Stunden
Gesamtzeit
Gesamtkosten
96-200 Stunden
weniger als $5,000-$10,000
40-80 Stunden
Wenn Sie Migration von DDL/Daten mit Migration der Geschäftslogik vergleichen, werden
Sie sehen, dass die letztere bis zu 95% der Gesamtkosten für ein Prokekt betragen kann.
Das ist immer für große Projekte der Migrationen von Oracle nach MySQL gültig.
Risikominderung für Konvertierung der Geschäftslogik
Wenn es viele Codezeilen für Konvertierung gibt und wenn vielfältige DatenbankMerkamale von Oracle benutzt werden, dann müssen Sie einige wichtige Schritte
verfolgen, um alles zu konvertieren.
•
Erfahrung
Das Personal, das für ein Migrationsprojekt verantwortlich ist, muss Entwickler
einschließen, die Verwaltungskompetenz und Erfahrung sowohl in Oracle als auch in
MySQL besitzen. Sie müssen Größe, Herausforderungen, Aufgaben und Phasen einer
Migration verstehen, um eine Migration erfolgreich zu erfüllen.
• Allumfassende Bewertung
Am Anfang müssen Sie die allumfassende Bewertung der Datenbanken machen. Endlich
werden Sie wissen, welche Funktionalität Sie konvertieren müssen, welche Lösungen Sie
verwenden werden, um die nicht-ANSI-konforme Oracle Merkmale zu ersetzen.
Sie müssen bestimmen, ob es eine Lösung für jedes verwendete Merkmal gibt oder nicht.
Das ist nicht einfach, für einige Oracle Merkmale Äquivalente in MySQL zu finden, deshalb
Sie müssen die Oracle-Funktionalität manchmal völlig umbauen.
•
Proof-of-Concept für vollständigen Code
Automatisierte Werkzeuge wie SQLWays können Konvertieungen des vollständigen Code am
Anfang der Bewertung einer Migrationrealisieren. Es wird von uns emfohlen das für jede
komplizierte Migration zu machen, denn dadurch können Sie mögliche Probleme enthüllen
und den möglichen Automatisierungsgrad und Erfolgsfaktor einer Migration mithilfe eines
Werkzeugs feststellen.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
8
Umso mehr, dann werden Sie sicher, dass Konvertierung vom schwierigen PL/SQL Code zu
einem niedrigen Preis machbar ist.
•
Automatisierte Migration möglichst oft verwenden
Gemeinsam mit dem hohen Preis reduziert manuelle Migration die Erkennbarkeit der
Probleme während einer Anfangsphase, dass kann dazu führen, dass Sie die Migration
später umbauen müssen werden. Dadurch werden Aufwände und Kosten noch erhöht.
Im Vergleich dazu kann die Konvertierung mit Hilfe von automatisierten Werkzeugen zu
einem niedrigen Preis ständig wiederholt werden, und dabei gibt es immer zuständige
Feedback. Dadurch werden Sie Migrationen von hoher Qualität haben ohne erhebliche
Kostennachteile.
Insgesamt ist manuelle Konvertierung eine bemühende Aufgabe, die oft zu menschlichen
Fehler führt. Oft haben Entwickler verschiedene Ergebnisse einer Konvertierung für
den gleichen Code. Endlich führt das zu erheblichen Kosten und Zeitverlust während der
Prüfungsphase.
• Anfangsprüfung
Anfangsprüfungen werden gebraucht, um Projektrisiken zu minimieren. Sie können
Modulteste durchführen oder den Code übersehen, sogar wenn funktionale Teste auf der
Anwendungsebene noch nicht verfügbar sind.
Sie können Merkmale automatisierter Werkzeuge benutzen, um Testfälle zu generieren und
Prozeduren und Funktionen mit spezifischen Werten auzurufen und Ergebnisse zu
vergleichen. Bitte bemerken Sie, dass funktionale Teste dann jedenfalls auf der
Anwendungsebene durchgeführt werden müssen, aber die vorbeschriebene Methode auch
viele mögliche Probleme der Konvertierung entdecken kann.
Konvertierung einer Anwendung
Gemeinsam mit Konvertierung der Geschäftslogik auf der Serverseite in meisten
Fällen müssen Sie auch Ihre Anwendungen modifizieren, um mit MySQL zu arbeiten.
Manchmal gibt es nicht-ANSI SQL-Anweisungen in Java oder PowerBuilder
Anwendungen, i.e. Syntax, die von MySQL SQL-Syntax sich unterscheidet und
modifiziert werden muss.
Die typische Merkmale von Oracle-Syntax, die größte Sorgen bei der Migration von Oracle
nach MysSQL machen, sind Left Outer Join (+) Syntax-Scripte. Funktionen wie DECODE,
NVL, und SYSDATE müssen auch sorgfältig behandelt werden.
Sie können Namen der Funktionen nicht einfach durch Suchen/Ersetzen in solcher
Situationen ersetzen. In vielen Fällen haben Funktionen Syntax mit verschiedenen
Parametern oder brauchen sie Veränderungen von SQL-Anweisungen wie z.B. von left
outer join.
Umso mehr, Ersatz der Zeichenketten kann den Text in unbeabsichtigten Plätzen ändern,
wie z.B. Charakter einer Zeichenkette oder Anweisungen in Java-Sprache.
Die beste Behandlung ist ein Werkzeug wie z.B. SQLWays benutzen, das
automatisch den Code einer Anwendung modifizieren und SQL-Anweisungen nach
entsprechender MySQL Syntax konvertieren kann.
Solche Werkzeuge können richtig SQL-Anweisungen im Code identifizieren,
Konvertierung durchführen, Berichte über alle Veränderungen generieren und dadurch
die Konvertierung einer Anwendung erleichtern.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
9
Planung – Phasen einer Migration
Ausführliche Planung ist sehr wichtig für erfolgreiche Migration, und typische Phasen einer
Migration sind:
•
Bewertung
Bewertung (die früher in diesem Dokument beschrieben wurde) ist notwendig, um
Datenbanken und Anwendungen, die Sie migrieren möchten, zu analysieren, die Größe
einer Migration zu bestimmen, und jede spezifische Oracle Funktionalität, die nach
MySQL umgebaut werden muss, festzustellen.
Mit Bezug auf die Information, die während der Bewerungsphase gesammelt wurde,
können Sie Behandlungen bestimmen, die gebraucht werden müssen (manuelle oder
automatisierte Konvertierung), als auch Kosten und Risiken der Migration.
•
Vollständige Konvertierung am Anfang – Proof-of-Concept
Wenn Sie z.B.eine Datenbank mit 2,000 Prozeduren haben, können Sie SQLWays
verwenden, um den vollständigen Code zu konvertieren während der Phase Proof-ofConcept. Diese Methode wird von uns empfohlen, sogar wenn Sie entschieden haben,
jeden einzelnen Modul zu testen.
Ganz am Anfang während dieses Prozesses (wenn automatisierte Werkzeuge benutzt
werden) werden Feedback und Erkennbarkeit in Bezug auf Migration verfügbar. Das ist ein
direkter Kontrast zur manuellen Migration, bei der viele Arbeitsstunden gebraucht werden
bevor es klar wird, dass es ein Fallstrick bei der Migration gibt, und dass ein Rückschritt
benötigt ist.
Sie können einen integrierten und einheitlichen Ansatz verwenden durch Benutzung von
einem der automatisierten Lösungen wie SQLWays. Weil verschiedene Mitarbeiter
verschiedene Aufgaben einer Migration gleichzeitig lösen, werden sehr oft verschiedene
Behandlungen und Prozeduren für die gleiche Syntax verwendet. Aber endlich ist es
einfacher, eine Migration prüfen und modifizieren, wenn die Ergebnisse der Migration
integriert und einheitlich sind.
Idealerweise werden 100% fehlerfreie Objekte in MySQL während einer Anfangsphase
geschaffen. Darunter versteht man, dass alle Tabellen, Funktionen, Prozeduren, Trigger
erfolgreich in MySQL geschaffen wurden.
Weil 100% Automatisierungsgrad einer Konvertierung ist ziemlich schwer zu erreichen für
jede Version aller Konvertierungswerkzeuge. Deshalb bietet Ispirer-Team kostenlose
Customization an (1-2 Tage für eine Einstellung), um fast 100% Automatisierung ganz am
Anfang während einer Bewertungsphase festzustellen.
• Laufzeitteste, logische Teste und Prüfungen der Leistungen
Migration wird oft für jeden einzelnen Modul durchgeführt. Nachdem Sie
Geschäftslogik auf der Serverseite konvertiert haben, sogar bevor Anwendungen
konvertiert worden sind und Teste auf der Anwendungsebene verfügbar sind,
müssen Sie Konvertierung einer Datenbank prüfen.
Sie können einige repräsentative oder kritische Prozeduren wählen und Übersicht vom Code
machen. Natürlich können Sie alle Probleme der Konvertierung sogleich nicht enthüllen,
aber jedenfalls ist das am Anfang einer Migration sehr nützlich. Mit diesem Code können Sie
ansehen, wie die Lösungen angewendet werden, und die Qualität einer Konvertierung
bewerten .
Das wäre prima, eine Liste der Charakteristika einer Konvertierung zu machen, die Sie
ausführlich analysieren können.
Sogar wenn Sie eine Prozedur oder Funktion in einer Datenbank erschaffen können, ist das
nicht selbstverstädlich, dass es keine kritische Fehler gibt. Viele Fehler nach der Ausführung
der Prozeduren entdeckt werden können. Eine einfache und effektive Weise von Prüfung der
Prozeduren ist Testfälle zu generieren.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
0
SQLWays kann eine Reihe von Prozedur-Aufrufen mit verschiedenen input Parametern
generieren. Durch Übersicht des Code, kann SQLWays entdecken, welche Werte,
Zeichenketten und Datenkonstanten, Bedingungen der Flusskontrolle benutzt werden, und
vernünftige Testfälle in vielen Situationen generieren.
Um allumfassende und leistungsfähige Teste der Logik und Leistungsprüfungen
durchzuführen, Können Sie Testscripte mit realen Daten aufbauen und dabei verschiedene
Szenarien realisieren.
Wenn Sie automatisierte Software für Qualitätssicherung Ihrer Oracle Datenbank und
Anwendungen benutzen, können Sie auch diese Software modernisieren um sie auf MySQL
zu verwenden und allumfassende Migrationsteste sicherzustellen.
Typische Lösungen für Konvertierung - Muster
Obwohl Aufgaben und Lösungen für Konvertierung abhängig vom Projekt sich
unterscheiden, sind viele von ihnen typisch für alle Migrationen.
Achtung. Alle Konvertierungen, die hier unten beschrieben werden, werden von SQLWays
automatisch durchgeführt.
DDL
Sowohl Oracle als auch MySQL unterstützen eine CREATE TABLE Anweisung, aber es gibt
viele Unterschiede in Syntax.
•
Datentypen
Oracle
CREATE TABLE employees
(
id NUMBER(5),
name VARCHAR2(120),
hire_date DATE,
salary NUMBER(7),
dept_id NUMBER(2)
);
•
MySQL
CREATE TABLE employees
(
id INT,
name VARCHAR(120),
hire_date DATETIME,
salary INT,
dept_id TINYINT
);
Reservierte Wörter
Oracle und MySQL benutzen verschiedene Sets von reservierten Wörter, deshalb müssen
einige Spaltennamen in MySQL-Anfragen (Queries) angegeben werden.
Oracle
MySQL
SELECT product_id, limit
FROM product_data;
SELECT product_id, `limit`
FROM product_data;
Queries und PL/SQL Code
Sie müssen SQL-Anweisungen modifizieren meistens um Syntax von Funktionen und
Ausdrücken zu verändern. PL/SQL muss völlig nach MySQL SQL prozeduraler Syntax
konvertiert werden .
• Outer Joins
Oracle unterstützt spezifische Syntax von Outer Joins, die in alten Anwendungen verbreitet ist.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
1
Oracle
MySQL
SELECT e.name, d.name
FROM employees e, departments d
WHERE e.dept_id = d.id(+);
SELECT e.name, d.name
FROM employees e LEFT OUTER JOIN
departments d ON e.dept_id = d.id;
•
der Spalten ID-Werte zuweisen
Oracle unterstützt keine Auto-Increment- (Identität)-Spalten, und ein Sequenz-Objekt
wird benutzt, um neue ID-Werte aus der Anwendung oder Trigger zuzuweisen.
Obwohl ein einzelnes Objekt benutzt werden kann, um Werte der multiplen Tabellen in
Oracle zuzuweisen, wird es in vielen Fällen nur für eine Tabelle verwendet, und diese
Funktionalität kann nach einer Auto-Increment Spalte in MySQL konvertiert werden.
Während automatisierter Konvertierung untersucht SQLWays SQL-Anfragen und INSERTAnweisungen in Anwendungen, Prozeeduren und Trigger um ID-Zuweisung zu
identifizieren und sie nach Auto-Increment Spalten in MySQL zu konvertieren.
Oracle
MySQL
CREATE TABLE employees
(
id NUMBER(5) PRIMARY KEY,
name VARCHAR2(120),
hire_date DATE,
dept_id NUMBER(2)
);
CREATE TABLE employees
(
id INT AUTO_INCREMENT PRIMARY
KEY,
name VARCHAR(120),
hire_date DATETIME,
dept_id TINYINT
);
CREATE TRIGGER emp_id BEFORE
INSERT ON employees
FOR EACH ROW
BEGIN
SELECT emp_id_seq.nextval
INTO :new.id FROM dual;
END;
•
-- Trigger is no required anymore
Multiple Trigger in einem Ereigniss
In Oracle können Sie für eine Tabelle einige verschiedene Trigger für das gleiche
Ereigniss definieren (fzum Beispiel, einige Trigger in einem INSERT-Ereigniss für
"Employees table" (Angestellte-Tabelle).
Das ist in MySQL unmöglich, weil Sie müssen den ganzen Code für ein Ereigniss im
derselben Trigger einsetzen.
•
Packages und gemeinsame Variablen
In Oracle ist ein Package eine Reihe von verbundenen Prozeduren und Funktionen, die
Variablen teilen können. Prozeduren und Funktionen vom Package müssen nach einzelnen
Objekten in MySQL konvertiert werden.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
2
Variablen von Packages können auf eine Prozedur vom Package modifiziert werden.
Umso mehr, andere Package-Prozedur kann einen modernisierten Wert sichten oder
ersetzen. Um diese Funktionalität in MySQL zu ersetzen, können Sie SessionVariablen, die mit dem Zeichen @ anfangen, benutzen.
Oracle
MySQL
CREATE PACKAGE BODY emp_pack
AS
CREATE PROCEDURE new_employee
BEGIN
…
IF @processed IS NULL
THEN @processed = 0;
processed NUMBER DEFAULT 0;
PROCEDURE new_employee AS
BEGIN
…
processed := processed + 1;
END;
PROCEDURE raise_salary AS
BEGIN
…
processed := processed + 1;
END;
END;
•
@processed = @processed + 1;
END;
CREATE PROCEDURE raise_salary
BEGIN
…
IF @processed IS NULL
THEN @processed = 0;
@processed := @processed + 1;
END;
END;
Rückkehr von Resultsets
Sie müssen CURSOR-Variablen benutzen (REF CURSORs) als OUT Parameter um
Resultset von Oracle zurückzusenden. In vielen Fällen kann das einfach nach
SELECT-Anweisung in MySQL konvertiert werden.
Oracle
MySQL
CREATE PROCEDURE get_salaries
(d_id IN NUMBER, cur OUT
SYS_REFCURSOR)
AS
BEGIN
OPEN cur FOR
SELECT id, name, salary
FROM employees
WHERE dept_id = d_id
ORDER BY name;
CREATE PROCEDURE get_salaries (IN d_id
INT)
BEGIN
SELECT id, name, salary
FROM employees
WHERE dept_id = d_id
ORDER BY name;
END;
END;
•
%TYPE und %ROWTYPE Definitionen der Datentypen
Oracle %TYPE-Attribut erlaubt Ihnen, Datentypen für PL/SQL Variablen definieren, die sich
auf Typen der Spalten von Tabellen basieren. In MySQL müssen Sie den Datentyp
ausdrücklich spezifizieren.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
3
Auf der ähnlichen Weise erlaubt Ihnen ein %ROWTYPE-Attribut, Record-Variablen zu
erschaffen, die sich auf Reihen der Tabellen basieren. In MySQL müssen Sie einzelne
Variablen erschaffen und ihre Datentypen ausdrücklich spezifizieren.
Oracle
MySQL
v_emp_name employees.name%TYPE;
v_emp_name VARCHAR(120)
v_emp_rec employees%ROWTYPE;
v_
v_
v_
v_
v_
•
emp_id INT
emp_name VARCHAR(120)
emp_hire_date DATETIME
emp_salary INT
emp_dept_id TINYINT
SQL-Konvertierung in Java Anwendungen
In Java Anwendungen vielleicht werden Sie brauchen, Syntax der SQL-Anweisungen zu ändern.
Oracle
…
PreparedStatement ps = null;
ResultSet rs = null;
String sql = “SELECT e.name, d.name” +
“FROM employees e, departments d” +
“WHERE e.dept_id = d.id(+)”;
MySQL
…
PreparedStatement ps = null;
ResultSet rs = null;
String sql = “SELECT e.name, d.name” +
“FROM employees e LEFT OUTER JOIN” +
“departments d ON e.dept_id = d.id”;
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
…
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
…
•
SQL-Konvertierung in PowerBuilder Anwendungen
In PowerBuilder Anwendungen vielleicht werden Sie auch brauchen, Syntax der SQLAnwendungen ändern.
Oracle
MySQL
datawindow(units=0 processing=0
datawindow(units=0 processing=0
print.orientation = 0
print.orientation = 0
…
…
print.preview.buttons=no)
print.preview.buttons=no)
table(column=(type=char(120)
table(column=(type=char(120)
updatewhereclause=yes name=e_name updatewhereclause=yes name=e_name
dbname="employees.name" )
dbname="employees.name" )
column=(type=char(120)
column=(type=char(120)
updatewhereclause=yes name=d_name updatewhereclause=yes name=d_name
dbname="departments.name" )
dbname="departments.name" )
retrieve="SELECT e.name, d.name
retrieve=" SELECT e.name, d.name
FROM employees e, departments d
FROM employees e LEFT OUTER JOIN
WHERE e.dept_id = d.id(+)”)
departments d ON e.dept_id = d.id”)
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
4
Problemumgehungen für nicht unterstützte Funktionalität
Es gibt viele Merkmale in Oracle PL/SQL, die in diesem Moment von MySQL SQL
prozeduraler Sprache nicht unterstützt werden. Wenn diese Funktionalität in einer QuelleDatenbank benutzt wird, müssen Sie verschiedene Problemumgehungen anwenden, um
das gleiche Benehmen in MySQL zu erhalten. Hier gibt es einige spezifische Muster:
•
PL/SQL Sammlungen
Sie können temporale Tabellen und SQL DML Operationen benutzen (SELECT, INSERT,
UPDATE, DELETE) um dieses Merkmal in MySQL zu ersetzen.
•
RAISE_APPLICATION_ERROR
Sie können ein UDF benutzen um einen Fehler aus MySQL gespeicherten Prozeduren
hervorzurufen.
•
UTL_FILE eingebettetes Package
Sie können ein UDF benutzen um mit Dateien aus MySQL gespeicherten Prozeduren zu arbeiten.
•
Komplizierte Geschäftslogik
Als eine Standardlösung kann komplizierte PL/SQL Geschäftslogik nach Java Sprache konvertiert
werden.
Abschluss
Automatisierte Migration nach MySQL Lizenzierungsmodell bietet eine attraktive
Wertsteigerung. Indem Sie SQLWays von Ispirer für schwierige Projekte der Migration
von Oracle nach MySQL benutzen, erhöhen Sie die Qualität Ihrer Arbeit und dabei
sparen Sie Zeit und Geld. Es gibt viele Aspekte, auf die Sie Rücksicht nehmen
müssen, wenn Sie sich für Migration der Geschäftslogik und Objekte einer Datenbank
entschieden haben. Ausführliche Planung, Analyse und Liebe zum Detail sind wichtig für alle
Phasen des Migrationsprojekts.
Obwohl die komplizierte Datenbank-Migration von Oracle nach MySQL mit Konvertierung
der Geschäftslogik eine schwierige Aufgabe ist, richtige Behandlungen und Benutzung
automotisierter Werkzeuge erlauben Ihnen, eine Migration zu einem niedriegen Preis und
mit wenig Risiko durchzuführen. Das Produkt von Ispirer SQLWays und Services von Ispirer
gewährleisten hohe Qualität bei der komplizierten Konvertierung der Geschäftslogik.
Copyright © 1999-2013. Ispirer Systems Ltd. Alle Rechte vorbehalten.
1
5