MIGRATION D'ORACLE VERS MYSQL - LIVRE BLANC PROCÉDURES STOCKÉES, PACKAGES, TRIGGERS, SCRIPTS ET APPLICATIONS

 
MIGRATION D'ORACLE VERS MYSQL - LIVRE BLANC PROCÉDURES STOCKÉES, PACKAGES, TRIGGERS, SCRIPTS ET APPLICATIONS
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
MIGRATION D'ORACLE VERS MYSQL - LIVRE BLANC PROCÉDURES STOCKÉES, PACKAGES, TRIGGERS, SCRIPTS ET APPLICATIONS
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.                             6
Certains 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.                             7
Un é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.                             8
Plus 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.                            9
Planification - 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
                                                                                             0
SQLWays 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
                                                                                               1
Oracle                                       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
                                                                                             2
Les 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
                                                                                           3
De 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
                                                                                            4
Solutions 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
                                                                                            5
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler