MIGRATION D'ORACLE VERS MYSQL - LIVRE BLANC PROCÉDURES STOCKÉES, PACKAGES, TRIGGERS, SCRIPTS ET APPLICATIONS
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Migration d'Oracle vers MySQL
Procédures Stockées, Packages, Triggers, Scripts et Applications
Livre Blanc
Mars 2009, Ispirer Systems Ltd.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
Introduction L'objectif de ce livre blanc est de décrire les facteurs qui influent la migration de base de données et d'applications d'Oracle vers MySQL. Les facteurs de coûts et les risques seront détaillées, ainsi que des outils et des méthodologies pour aider à atteindre une conversion de qualité supérieure. Il est très vrai que la base de données Sun MySQL peut réduire considérablement le Coût total de possession (TCO) de la base de données pour une entreprise en réduisant les coûts de licence, matériel et administration. Le plus grand risque dans le déplacement de la plate-forme MySQL est le risque et la complexité de la migration de la logique métier d'Oracle, en particulier lorsque les applications existantes font un usage important de procédures PL / SQL, les triggers, les forfaits et les instructions SQL spécifiques à Oracle. La migration d'Oracle vers MySQL peut être gênant, fastidieux et coûteux. Cependant, les méthodes et outils éprouvés peuvent réduire le coût et le temps requis et peuvent atténuer considérablement le risque. Avec l'aide des de produits de migration SQLWays, la migration peut être évaluée, planifiée et correctement automatisée. Avec l'utilisation appropriée des outils automatisés et un processus de gestion de projet solide en place, les entreprises peuvent engager des économies de plus de 70% par rapport aux techniques traditionnelles de migration manuelle. Couplé avec les économies réalisées grâce à la mise en œuvre MySQL, la migration automatisée devient une alternative très attrayante. Défis La base de données Oracle offre des fonctionnalités très avancées pour développer la logique de l'application qui se trouve entièrement à l'intérieur de la base de données en utilisant PL / SQL procédures stockées, des fonctions, des packages et les triggers. Oracle PL / SQL est une extension facile à utiliser et puissante pour SQL qui est fortement recommandée par Oracle pour des raisons de performances. Dans la plupart des applications, l'utilisation de PL / SQL conduit naturellement à une significative grande nombre de procédures, packages et des déclencheurs. MySQL, bien qu'ayant certaines fonctionnalités similaires, ne pas faire usage de PL / SQL. Outre la syntaxe spécifique Oracle, PL / SQL offre de nombreuses fonctionnalités non compatibles ANSI, y compris les caractéristiques qui ne se retrouvent dans Oracle. Ces caractéristiques d'Oracle comprennent: • Packages - shared package variables, built-in packages • %TYPE, %ROWTYPE, exceptions • Fonctionnalités orientées objet: les types d'objets, fonctions et collections • Business Intelligence et XML caractéristiques etc Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 2
Une migration d'Oracle à MySQL peut être un processus très difficile, en particulier si les fonctionnalités spécifiques à Oracle sont utilisés, tels que décrites ci-dessus. Cependant, une telle migration pourrait être relativement facile et sans risque. Tel serait le cas si la base de données cible contient une quantité relativement faible de tables et de la logique métier simple. Depuis que les coûts et les risques peuvent se varier d'un projet à l'autre, il est important de réaliser une évaluation préliminaire. Évaluation Le but de cette évaluation est de définir la portée, la faisabilité, le coût et le risque associés à la migration d'une base de données d'Oracle à une application de base de données basé sur MySQL. Évaluation de base de données Tout d'abord, vous devez définir les types d'objets de base de données et combien d'entre eux vous aurez besoin de migrer. Les objets sont des éléments tels que les suivants: • Tables • Vues • Procédures • Fonctions • Packages • Triggers • Séquences, synonymes etc. Si vous avez besoin de convertir code PL / SQL (procédures, packages, fonctions et les triggers) ou vues / requêtes contenant la syntaxe SQL spécifique d'Oracle, vous devez étudier quelles fonctionnalités sont utilisées et définir le nombre de leurs occurrences. Des exemples d'éléments qui doivent être pris en compte sont: • Non-ANSI compatible SQL fonctions, operators et déclarations • Results sets • Cursor loops • Exceptions • Temp tables • Types d'Objet et fonctions • Collections Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 3
• SQL Dynamique • Built-in packages • OLAP fonctions • XML fonctions etc. Une fois que vous avez terminé l'examen, il est préférable de choisir des équivalents ou des solutions MySQL pour remplacer des fonctionnalités spécifiques Oracle. Vous pouvez trouver des solutions typiques dans les chapitres suivants. Évaluation de l'application Outre schéma et la conversion de la logique métier côté serveur, vous pouvez aussi avoir besoin de modifier les instructions SQL dans l'application. Il est essentiel d'évaluer combien de ce travail devra être fait pour compléter la migration. Pour commencer, vous devez vérifier ce que l'API base de données est utilisée dans vos applications pour accéder à la base de données Oracle. Il est important de noter combien de fichiers source de l'application contiennet le code spécifique d'Oracle et donc il doit être modifié pour fonctionner avec MySQL. La plupart des applications utilisent une API standard comme ODBC, JDBC, et ADO.NET pour accéder à Oracle, mais certaines applications peuvent utiliser une API native comme Oracle OCI ou Pro * C / C + +. La collecte de toutes ces informations est impératif. Même si vous utilisez une API standard, comme l'utilisation de pilotes ODBC / JDBC, des changements importants peuvent être apportées aux instructions SQL existantes. Par exemple les fonctions de décoder ou héritage laissé de syntaxe de jointure externe (*) devra être modifié. Il est recommandé d'estimer le nombre de requêtes SQL natives. Si la demande arrive à utiliser une API native comme Oracle OCI, vous aurez besoin d'une refonte complète du code d'accès de base de données à utiliser l'API MySQL et ODBC. Évaluation d'Outils Il est important de comprendre combien il est fait usage des fonctionnalités de base de données spécifiques. Quelle est la meilleure évaluation de «l'utilisation de fonction» est effectuée? Commencez d'abord par le calcul du nombre de tables, procédures, des vues, etc, comme dans le tableau ci-dessous. Pour une analyse plus détaillée, vous pouvez utiliser le produit SQLWays de Ispirer de recueillir des statistiques complètes. Voici l'échantillon d'une évaluation: Base de Données Nombre Tables 350 Vues 280 Procédures 420 Fonctions 135 Triggers 50 Packages 10 Détails de BD BLOBs 37 Outer joins 155 Ref cursors 89 Excéptions 450 Temp tables 34 Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 4
Application Java/JDBC 590 de fichiers Outer joins 190 SQL functions 356 Result sets 47 Approche de la migration Conversion Automatisée Sur la base des résultats de l'évaluation, vous pouvez élaborer un plan de migration. Si vous avez des dizaines de procédures, vous pourriez envisager une conversion manuelle, mais si des centaines ou des milliers de procédures doivent être migré, il est préférable d'examiner les outils de migration automatisés sur le marché. SQLWays fournit une telle fonctionnalité. Coût et Risque Le coût et le risque associés au projet de conversion dépendent de l'ampleur de la migration. Il est important de noter que le coût et les risques sont également touchés par la diversité et la fréquence des fonctionnalités d'Oracle en usage dans la base de données et d'application. D'autres fonctionnalités d'Oracle en cours d'utilisation, le plus complexe et plus coûteuse est la conversion. En outre, plus les fonctionnalités d'Oracle sont en cours d'utilisation, les outils plus automatisés pourraient aider à atteindre le succès. Coût de la Migration de Données et DDL La migration des objets de données et DDL (Schéma) est effectuée d'habitude de manière facile, car il y a pleins d'outils dans le marché qui peuvent vous aider à réaliser ce type de la migration. La migration typique de Données et DDL implique la conversion de • Types de Données • Contraintes (clés primaires et étrangères, contraintes unique, NULL, défaut etc) • Transfert de Données • Indexes Bien qu'il existe des différences dans la syntaxe d'Oracle et des instructions DDL SQL, les deux ont des types de données similaires (caractère, nombre, date, heure, LOB) ce qui vous permet de préciser les contraintes d'intégrité similaires. L'échantillon de l'éstimation de la Migration de DDL/Données: Base de Données Tables
Outils Gratuit, soit moins de $500
Grâce à l'automatisation, le coût de la migration DDL et des données n'est pas
directement proportionnel au nombre de tables et de la taille des données. Par exemple,
le coût de la migration pour les 100 et 300 tables peut être similaire dans le coût, si les
tableaux ont une structure et la taille des données similaires.
Lorsque le nombre de tables et leur taille s'augmentent, vous devrez peut-être passer plus
de temps à configurer correctement la base de données MySQL, au transfert de données
d'un morceau, et de se concentrer sur des choses comme la performance de création
d'index.
Atténuation des risques pour la migration typique de DDL et des données
La migration typique DDL / données impose un risque relativement faible. En utilisant
SQLWays, il est possible d'exécuter le transfert de base de données complète en mode
d'évaluation, d'examiner les données et exécuter des applications liées à la nouvelle base de
données MySQL:
C'est workflow général:
1. Exécuter le transfert de base de données complète en mode d'évaluation
2. Vérifiez les erreurs de transfert, comparer les structures des tables, le nombre de
lignes dans d'Oracle et MySQL
3. Examiner et tester des données aux tableaux représentant et en utilisant l'outil SQL
d'Oracle SQL * Plus, MySQL Query Browser, ou l'utilitaire de ligne de commande mysql
4. Exécuter et tester l'application cible connecté à MySQL
Défis de la Migration de Données
Même si, en général, la migration de données / DDL est relativement facile par rapport à
la conversion de la logique métier, il y a certaines conditions qui augmentent
généralement la complexité de la migration de données / DDL:
• De grands volumes de données
Si vous avez besoin de migrer de grands volumes de données, vous devrez peut-être
pocéder plus d'efforts pour configurer les serveurs MySQL.
Une grande quantité de données peut influer sur le processus de migration, en particulier
en termes de temps qu'il faut pour terminer la migration. Afin d'atténuer le temps
nécessaire pour terminer la migration, vous pouvez exécuter la migration d'une manière
simultanée. Cela augmente la complexité de la migration.
En outre, le transfert d'un grand volume de données peut compliquer la gestion des erreurs,
comme vous pouvez maintenant se permettre de ré-exécuter une migration complète si
quelques tables échouent.
Le projet pourrait bénéficier d'outils qui permettent de vrac options d'insertion, comme des
outils qui émettent un commit après chaque rangée qui n'est plus une option viable.
• Temps d'arrêt minimal
Dans certains environnements critiques, vous devez vous assurer que les temps d'arrêt est
maintenu à un minimum. Pour répondre à ces exigences, vous devez bien concevoir le
processus de migration de faire des choses telles que le transfert des données de s'exécuter
simultanément, ou transférer des tables statiques de la fenêtre de temps d'arrêt. Parfois, les
outils de réplication doivent être utilisés pour réduire les temps d'arrêt.
• Exigences de performance rigoureuses
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 6Certains environnements ont des exigences très strictes en matière de performance pour
les applications. Lors de la migration de MySQL, il est impératif que la performance
existante est maintenue ou améliorée. Cela vous oblige à passer plus de temps sur la
conception de base de données et l'optimisation, ainsi que l'exécution des migrations tests
afin de tester les performances de suivi de migration.
Atténuation des risques pour contester DDL et de migration de données
Le défis de la migrations de données ne peut être complété par un simple double-clic. Une
migration Proof-of-Concept doit être exécuté afin de s'assurer que les exigences peuvent
être satisfaites.
Le plus souvent, le processus de migration suivante est recommandée pour les projets
complexes de migration de données:
• Proof-of-Concept migration pour vérifier la faisabilité des exigences
Migration de test pour émuler complètement migration de production et exécuter des
•
tests complets
• La migration de la production
Coût de conversion de la logique métier
Si votre base de données contient une douzaine de procédures et les triggers, il est facile
de réécrire manuellement à la syntaxe MySQL SP. Mais si vous avez des milliers de
procédures et les triggers, conversion manuelle est assez cher. Vous devez considérer
comment un outil automatisé peut vous aider.
Le coût de la conversion manuelle est directement proportionnelle au nombre de lignes de
code que vous devez convertir. D'autre part, les outils automatisés peuvent limiter les
coûts, et de faire la migration de même un million de lignes de code très raisonnable en
coût et l'effort.
Selon les lignes de code être convertis, la conversion automatique de la logique métier en
utilisant un outil comme SQLWays peut coûter 7-10 fois moins que la conversion manuelle
.
La diversité et la fréquence des fonctionnalités spécifiques à Oracle définit la complexité
des affaires migration logique et le niveau d'automatisation fourni par outils.
Pour une automatisation efficace, nos experts estiment qu'un outil de migration comme
SQLWays doit être capable de convertir plus de 95% de la logique métier.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 7Un échantillon d'estimation de la migration de logique métier côté serveur se présente comme
suit:
Base de Données
Procédures Stockées 1000
Triggers 300
Fonctions 250
Packages 10 (50 procédure par package)
Conversion manuelle 5,000 h (~30 mois-homme)
Coût du travail $50,000-$250,000 (selon le
pays)
conversion automatique
Évaluation, discussion 16-40 h
des solutions
conversion itérative, 40-80 h
l'analyse
Test 40-80 h
Durée totale 96-200 h
Coût d'outils moins que $5,000-$10,000
Si vous comparez la migration de DDL / données et de logique métier, vous pouvez voir
que celui-ci peut faire jusqu'à 95% du coût total du projet. Cela est particulièrement vrai
pour les grands projets de migration d'Oracle vers MySQL.
Atténuer les risques pour la Conversion de la Logique Métier
S'il ya beaucoup de lignes de code pour convertir, et une grande diversité de
fonctionnalités de base de données d'Oracle sont utilisés, la conversion peut imposer des
risques importants, de sorte que vous devez prendre plusieurs mesures importantes pour
atténuer.
• Expérience
Le personnel responsable du projet de migration doit avoir et les compétences
administratives et de l'expérience développeur à la fois pour les bases de données Oracle
et MySQL. Ils doivent comprendre clairement la portée, les défis, les tâches et les étapes
à mettre en œuvre avec succès la migration.
• Evaluation globale
Au stade initial, vous devez effectuer une évaluation complète des bases de données que
vous souhaitez migrer. En conséquence, vous saurez ce que la fonctionnalité spécifique
dont vous avez besoin pour convertir, quelles sont les solutions que vous allez utiliser pour
remplacer les fonctionnalités d'Oracle conformes à non-ANSI.
Vous devez déterminer si il ya une solution pour chaque fonction en cours d'utilisation.
Certaines fonctionnalités d'Oracle ne sont pas faciles à correspondre à un équivalent
similaire dans MySQL, vous devrez donc de repenser certaines fonctionnalités.
• Proof-of-Concept pour le code complet de base
Les outils automatisés comme SQLWays permettent d'exécuter facilement des conversions
sur la base de code complète au début de l'évaluation de la migration. Nous vous suggérons
de faire cela dans le cadre d'une migration complexe, car cela aidera à exposer les goulets
d'étranglement potentiels et de mieux clarifier "le pour cent de l'automatisation" ou facteur
de réussite de l'outil de migration fourni.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 8Plus important encore, il vous rendra confiant que la conversion du lourd code PL / SQL
est réalisable à faible coût.
• Utilisez migration automatisée autant que possible
En plus de son coût élevé, la migration manuelle réduit la visibilité des goulots
d'étranglement dans les premiers stades, ce qui peut entraîner la nécessité de repenser la
migration. Cela augmente encore l'effort et le coût de la migration.
Par comparaison, les outils automatisés permettent la conversion devant être exécuté à
plusieurs reprises pour un faible coût, mais avec des niveaux élevés de rétroaction. Cela
permet de migrations hautement raffinées et à l'écoute sans pénalités significatives de
coûts.
En général, la conversion manuelle est une tâche fastidieuse qui conduit à une forte
probabilité d'erreur humaine. Très souvent, les développeurs peuvent souvent produire des
résultats différents de conversion pour un code similaire. En conséquence, ce qui conduit à
de grands problèmes de coût et de temps pour les tests.
• Test précoce
Les tests à des stades précoces doivent également servir à réduire le risque du projet.
Vous pouvez exécuter des tests unitaires, ou d'effectuer des revues de code, même si les
tests fonctionnels au niveau de l'application ne sont pas encore possible.
Vous pouvez utiliser les fonctionnalités d'outils automatisés qui peuvent générer des cas de
test pour invoquer les procédures et fonctions avec des valeurs spécifiques et comparer les
résultats. Veuillez noter que cela ne peut pas remplacer les tests fonctionnels au niveau de
l'application, mais il peut aider à découvrir de nombreux problèmes potentiels.
Conversion d'Application
Outre la conversion de la logique métier côté serveur, dans la plupart des cas, vous devez
modifier vos applications pour travailler avec MySQL.
Il peut y avoir des instructions SQL non-ANSI dans Java ou des applications PowerBuilder,
c'est la syntaxe qui diffère de la syntaxe SQL MySQL et doit être modifiée.
Plus précisément, les fonctions syntaxiques les plus typiques qui ont besoin d'attention
pour les conversions d'Oracle à MySQL sont Oracle jointure externe gauche (+) des scripts
de syntaxe. Des fonctions comme DECODE, NVL et SYSDATE tous auront besoin
d'attention.
Vous ne pouvez pas remplacer des noms de fonctions à l'aide de Rechercher / Remplacer
dans ces situations. Dans de nombreux cas, les fonctions peuvent avoir la syntaxe de
paramètre différent, ou exiger des modifications d'instructions SQL telles que la jointure
externe gauche.
En outre, les remplacements de chaînes simples peuvent changer le texte dans des
endroits inattendus, comme des chaînes de caractères, ou des instructions en langage
Java.
La meilleure approche consiste à utiliser un outil comme SQLWays qui est capable de
modifier automatiquement le code d'application et la conversion des instructions SQL pour
MySQL syntaxe correcte.
Ces outils peuvent identifier correctement les instructions SQL dans le code, effectuer la
conversion, et générer des rapports sur tous les changements, ce qui simplifie
grandement la tâche de conversion de l'application.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 9Planification - Etapes de migration
Une bonne planification est très importante pour une migration réussie, et les étapes de
migration habituelles sont les suivantes:
• Evaluation
L'évaluation (qui est décrit précédemment dans ce document) est destinée à analyser les
bases de données et applications dont vous avez besoin de migrer, définir la portée de la
migration, et de documenter toute fonctionnalité spécifique d'Oracle qui devra être mis en
correspondance avec MySQL.
Sur la base des informations recueillies par l'évaluation, vous pouvez définir quelles
approches doivent être utilisées (conversion manuelle ou automatique) et le coût et les
risques qui sont associés à la migration.
• Conversion complète à un stade précoce – Proof-of-Concept
Supposons que vous avez une base de données avec 2.000 procédures. Vous pouvez
exécuter SQLWays de convertir la totalité de la base de code lors des étapes preuve de
concept. Ceci est suggéré, même si vous décidez de tester et de déployer module par
module.
Très tôt dans le processus (lorsque les outils d'automatisation sont utilisés), la rétroaction
et la visibilité sont disponibles en ce qui concerne la migration. Ceci est en contraste direct
à une migration manuelle où de nombreuses heures de travail peuvent souvent être dédié
aux tâches avant de réaliser le processus de migration a rencontré un écueil et doit revenir
en arrière.
Vous pouvez appliquer une approche de migration plus intégrée et uniforme à l'aide de
solutions automatisées comme SQLWays. Très souvent, les tâches de migration manuelle
sont répartis entre différentes personnes au sein d'une organisation, des procédures
différentes, les approches sont souvent utilisées pour la même syntaxe. En conséquence,
plus les résultats d'une migration sont uniformes et intégrés, plus il sera facile de tester et
de modifier.
Idéalement, vous avez besoin pour atteindre près de 100% sans erreur la création d'objets
dans MySQL à un stade précoce. Cela signifie que toutes les tables, les fonctions, les
procédures, les trigger sont créés avec succès dans MySQL.
Puisque 100% de conversion est très difficile à atteindre pour toutes les bases de données
dans la version actuelle de n'importe quel outil de conversion, l'équipe de Ispirer offre la
personnalisation gratuite (1-2 jours par fix) pour atteindre près de 100% d'automatisation
lors de l'évaluation initiale.
• Run-Time, Test logique et de performance
La migration est souvent déployée module par module. Après avoir converti la logique
métier côté serveur, avant même que les applications sont converties et les tests de niveau
de l'application est possible, vous devriez tester la conversion de base de données.
Vous pouvez sélectionner plusieurs représentant ou procédures les plus critiques et
d'effectuer une revue de code. Bien sûr, vous ne pouvez pas trouver tous les problèmes
examen du code, mais au début, il est très utile. Avec le code, vous pouvez examiner
comment les solutions sont appliquées, et estimer la qualité de la conversion en général.
Il est préférable de créer une liste de conversion de fonction dont vous voulez étudier en
profondeur.
Même si vous pouvez créer une procédure ou une fonction dans la base de données, cela ne
signifie pas qu'il ne contient pas d'erreurs critiques. De nombreuses erreurs peuvent être
rapidement découvertes par l'exécution des procédures. Un moyen simple et efficace pour
tester les procédures est de générer des cas de test.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
0SQLWays peut générer une série d'appels de procédure avec les différents paramètres
d'entrée. En examinant le code, SQLWays peut savoir quelles valeurs, de la ficelle et des
constantes jour, les conditions de contrôle de flux sont utilisés, et de générer les cas de test
raisonnables dans de nombreuses situations.
Pour effectuer une logique plus globale et les tests de performance, vous pouvez développer
des scripts de test avec des données réelles, la mise en œuvre de divers scénarios.
Si vous utilisez un logiciel d'assurance qualité automatisée pour votre base de données et
applications Oracle, vous pouvez envisager de les mettre à jour pour fonctionner avec
MySQL et d'assurer les essais de migration globale.
Solutions de Conversion typique - Échantillons
Bien que les tâches et les solutions de conversion varient d'un projet à l'autre, beaucoup
d'entre eux sont typiques pour une migration.
Remarque. Toutes les conversions décrites ci-dessous sont effectuées par SQLWays
automatiquement.
DDL
Oracle et MySQL soutiennent la commande CREATE TABLE, mais il ya beaucoup de
différences de syntaxe.
• Types de Données
Oracle MySQL
CREATE TABLE employees CREATE TABLE employees
( (
id NUMBER(5), id INT,
name VARCHAR2(120), name VARCHAR(120),
hire_date DATE, hire_date DATETIME,
salary NUMBER(7), salary INT,
dept_id NUMBER(2) dept_id TINYINT
); );
• Mots Réservés
Oracle et MySQL utilisent de différentes séries de mots réservés, de sorte que certains
noms de colonnes doivent maintenant être cités dans les requêtes MySQL.
Oracle MySQL
SELECT product_id, limit SELECT product_id, `limit`
FROM product_data; FROM product_data;
Requêtes et Code PL / SQL
Vous devez modifier les instructions SQL principalement à modifier la syntaxe de fonctions
et expressions. PL / SQL doit être complètement transformée pour MySQL SQL syntaxe
procédurale.
• Jointure OUTER
Oracle prend en charge la syntaxe spécifique pour les jointures externes qui est largement
utilisé dans les anciennes applications.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
1Oracle MySQL
SELECT e.name, d.name 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;
• Affecter une valeur de ID de colonne
Oracle ne supporte pas les colonnes à incrémentation automatique (identité), et un objet
de séquence est utilisée pour assigner de nouvelles valeurs d'identité à partir d'une
application ou d'un déclencheur.
Même si un objet de séquence unique peut être utilisé pour attribuer des valeurs pour
plusieurs tables dans Oracle, dans de nombreux cas, il est utilisé pour une seule table et
cette fonctionnalité peut être convertie en colonne à incrémentation automatique dans
MySQL.
Pour la conversion automatisée, SQLWays inspecte les requêtes SQL et des instructions
INSERT dans les applications, les procédures et les triggers pour identifier l'affectation
d'identification et les convertir en colonnes à incrémentation automatique dans MySQL.
Oracle MySQL
CREATE TABLE employees CREATE TABLE employees
( (
id NUMBER(5) PRIMARY KEY, id INT AUTO_INCREMENT PRIMARY
name VARCHAR2(120), KEY,
hire_date DATE, name VARCHAR(120),
dept_id NUMBER(2) hire_date DATETIME,
); dept_id TINYINT
);
CREATE TRIGGER emp_id BEFORE
INSERT ON employees -- Trigger is no required anymore
FOR EACH ROW
BEGIN
SELECT emp_id_seq.nextval
INTO :new.id FROM dual;
END;
• Triggers multiples sur un seul événement
Dans Oracle, pour la même table, vous pouvez définir plusieurs triggers pour le même
événement (par exemple, plusieurs déclencheurs sur événement INSERT pour la table des
employés).
Ce n'est pas admissible dans MySQL, que vous devez mettre tout le code pour un
événement dans le même déclencheur.
• Packages et des Variables partagées
Dans Oracle, un package est un ensemble de procédures et de fonctions permettant le
partage des variables connexes. La procédure et la fonction du Package doivent être
converties en objets autonomes dans MySQL.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
2Les variables de package peuvent être modifiées dans une procédure de package. En
outre, une autre procédure de package peut voir ou relayer la valeur actualisée. Pour
remplacer cette fonctionnalité dans MySQL, vous pouvez utiliser des variables de session
qui commencent par signe @.
Oracle MySQL
CREATE PACKAGE BODY emp_pack CREATE PROCEDURE new_employee
AS BEGIN
…
processed NUMBER DEFAULT 0; IF @processed IS NULL
THEN @processed = 0;
PROCEDURE new_employee AS
BEGIN @processed = @processed + 1;
… END;
processed := processed + 1;
END; CREATE PROCEDURE raise_salary
BEGIN
PROCEDURE raise_salary AS …
BEGIN
… IF @processed IS NULL
processed := processed + 1; THEN @processed = 0;
END;
END; @processed := @processed + 1;
END;
END;
• Résultats du scrutin établit
Vous devez utiliser des variables de curseur (REF CURSOR) comme paramètre OUT
pour retourner un ensemble de résultats à partir d'Oracle. Dans de nombreux cas,
cela peut être converti à un simple SELECT dans MySQL.
Oracle MySQL
CREATE PROCEDURE get_salaries CREATE PROCEDURE get_salaries (IN d_id
(d_id IN NUMBER, cur OUT INT)
SYS_REFCURSOR) BEGIN
AS
BEGIN SELECT id, name, salary
FROM employees
OPEN cur FOR WHERE dept_id = d_id
SELECT id, name, salary ORDER BY name;
FROM employees
WHERE dept_id = d_id END;
ORDER BY name;
END;
• %TYPE et% ROWTYPE définitions de type de données
L'attribut % TYPE Oracle vous permet de définir les types de données pour les variables
PL / SQL basées sur les types de colonnes du tableau. Dans MySQL, vous devez spécifier
le type de données explicitement.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
3De la même manière, l'attribut %ROWTYPE vous permet de créer des variables
d'enregistrement en fonction des lignes de la table. Dans MySQL, vous devez créer des
variables autonomes et spécifier leurs types de données explicitement.
Oracle MySQL
v_emp_name employees.name%TYPE; v_emp_name VARCHAR(120)
v_emp_rec employees%ROWTYPE; v_ emp_id INT
v_ emp_name VARCHAR(120)
v_ emp_hire_date DATETIME
v_ emp_salary INT
v_ emp_dept_id TINYINT
• Conversion SQL dans les applications Java
Dans les applications Java, vous pouvez avoir besoin de modifier la syntaxe des instructions SQL.
Oracle MySQL
… …
PreparedStatement ps = null; PreparedStatement ps = null;
ResultSet rs = null; ResultSet rs = null;
String sql = “SELECT e.name, d.name” + String sql = “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”;
ps = conn.prepareStatement(sql); ps = conn.prepareStatement(sql);
rs = ps.executeQuery(); rs = ps.executeQuery();
… …
• Conversion SQL dans les applications PowerBuilder
Dans les applications PowerBuilder, vous pouvez aussi avoir besoin de changer la syntaxe des
instructions SQL.
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. Tous Droits Réservés. 1
4Solutions de contournement pour les fonctionnalités non prises
en charge
Il ya de nombreuses fonctionnalités d'Oracle PL / SQL qui ne sont pas actuellement prises
en charge par MySQL SQL langage procédural. Si cette fonctionnalité est utilisée dans la
base de données source, vous devez appliquer diverses solutions pour obtenir le même
comportement dans MySQL. Voici quelques exemples précis:
• PL/SQL Collections
Vous pouvez utiliser des tables temporaires et les opérations DML SQL (SELECT, INSERT,
UPDATE, DELETE) pour remplacer cette fonctionnalité dans MySQL.
• RAISE_APPLICATION_ERROR
Vous pouvez utiliser une UDF pour générer une erreur de procédures stockées SQL.
• UTL_FILE Built-in Package
Vous pouvez utiliser une UDF pour travailler avec des fichiers à partir de procédures
stockées SQL.
• Complex Business Logic
Comme une solution générale, complexe PL / SQL logique métier peut être convertie en langage
Java.
Conclusion
Automatiser la migration vers le modèle de licence MySQL fournit une valeur
incroyable. En utilisant SQLWays de Ispirer sur le complexe de projets de migration
d'Oracle vers MySQL augmente la qualité, vous permettant d'économiser temps et
argent. Il ya beaucoup de choses à garder à l'esprit lors de la planification sur la logique
métier de la migration et du contenu de la base de données pour une application existante.
Une bonne planification, l'analyse et l'attention aux détails sont nécessaires pour chaque
étape d'un projet de migration.
Bien que la migration de base de données complexe d'Oracle vers MySQL qui implique la
conversion de la logique métier est une tâche difficile, une approche appropriée et
l'utilisation d'outils de migration vous permettra d'exécuter des migrations à un faible coût
et avec minimum de risque. Le produit SQLWays de Ispirer et services de Ispirer peuvent
fournir une grande quantité de valeur lorsqu'il s'agit de conversion complexe de logique
métier.
Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés. 1
5Vous pouvez aussi lire
