Livre Blanc sur Ispirer MnMTK d`Oracle vers MySQL

Copyright © 1999-2013. Ispirer Systems Ltd. Tous Droits Réservés.
1
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.
2
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.
3
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.
4
• 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.
5
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
<100 tables
LOBs
10 colonnes
Max rangées en table
<10M
Max taille de tables
<300 Mb
Processus de Migration
Evaluation 2-8 h
MySQL configuration
4-16 h
Transfert Automatisé 2-4 h
Test, changement de
configuration, itération
suivante
4-12 h
Durée Totale 12-40 h