Il est vrai qu'Oracle n'est pas connu pour ses tarifs abordables. En même temps, il s'agit d'un des SGBD (Système de Gestion de Base de Données) les plus complets et puissants du marché.
Cependant, et je l'ai remarqué tout au long de ma carrière, cette base de données est souvent utilisée dans des cas ne la justifiant absolument pas, entraînant donc une perte d'argent conséquente, sans avantage aucun.
Cet article a pour objectif de décrypter les implications d'une telle migration, et de vous apporter quelques outils pour vous aider dans cette entreprise.
Faire un état des lieux de ce qui est présent dans la base de données
C'est l'étape la plus importante ! Avoir une bonne vision d'ensemble de ce qui est présent dans la base de données, va permettre de définir le temps qu'il faudra pour refactoriser l'application, et aussi, dans une moindre mesure, la base de données cible à utiliser, – ici, MySQL.
Dans mon cas, l'application est relativement simple. J'ai identifié les éléments suivants :
Tables & Vues
Des tables classiques et des VUES (tous les SGBDR sérieux en proposent en standard).
Procédures stockées
3 procédures stockées (ça devient un peu plus complexe, surtout pour des histoires de performances).
Indexes classiques
BTREE et FULLTEXT, des auto-increment (donc sous Oracle, des triggers et des séquences).
Types de données
Les types de données exotiques (JSON, XML, columns…)
Conclusion : Pas de trucs vraiment complexes, du genre vues matérialisées, partitions, DBLINK, réplication et autres joyeusetés. Ce projet ne nécessitait absolument pas Oracle pour tourner.
Définir le SGBD de remplacement
Dans notre cas, c'est MySQL qui a été choisi (on aurait également pu utiliser PostgreSQL).
Il faut faire très attention, certaines fonctionnalités d'Oracle (exemple : vues matérialisées) ne se retrouvent pas sur les SGBD gratuits, ni dans des versions vraiment basiques.
Ce sujet serait très vaste à couvrir, et il y a bien d'autres critères, beaucoup plus fins à prendre en compte, mais l'idée de cet article est de balayer, dans les grandes lignes, notre cas de figure : Oracle vers MySQL.
Migration des données de Oracle vers MySQL
Les trucs chiants à regarder de près
Casse des tables
Par défaut, la manière dont MySQL traite les noms de tables dépend du système de fichiers sur lequel sont stockées lesdites tables. En gros, pas d'importance sous Windows et macOS (enfin, pour ce dernier, ça dépend), les noms de tables ne sont pas sensibles à la casse – sous Linux, c'est une autre histoire.
Il est possible de changer ce comportement avec la variable lower_case_table_names.
De son côté, Oracle est systématiquement insensible à la casse des tables, c'est-à-dire que quelle que soit la manière dont vous avez lancé votre commande "CREATE TABLE", vous pourrez interroger les tables en utilisant n'importe quelle combinaison de casse.
null != empty string ('')
Alors là, on commence à entrer dans les trucs vraiment chiants ! Oracle considère que NULL == '', c'est-à-dire que taper une requête comme "update macol set field = '' where.." est équivalent à "update macol set field = NULL where..". Ce fonctionnement est un peu discutable, car dans certains cas il peut être utile de faire la différence entre une absence de données (je n'ai rien saisi) et une chaîne vide (j'ai saisi la donnée mais je ne peux pas encore la renseigner pour l'instant).
Séquences vs AUTO_INCREMENT
Oracle utilise des séquences combinées à des triggers pour gérer les identifiants auto-incrémentés, tandis que MySQL utilise simplement la propriété AUTO_INCREMENT.
Oracle :
CREATE SEQUENCE user_seq START WITH 1;
CREATE TRIGGER user_trigger
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
SELECT user_seq.NEXTVAL INTO :NEW.id FROM dual;
END;MySQL :
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
...
);Types de données
Les types de données entre Oracle et MySQL nécessitent une attention particulière lors de la conversion :
Oracle → MySQL
- • VARCHAR2 → VARCHAR
- • NUMBER → INT / DECIMAL
- • CLOB → TEXT / LONGTEXT
- • BLOB → BLOB
- • DATE → DATETIME
- • TIMESTAMP → TIMESTAMP
Attention particulière
- • NUMBER(10,2) → DECIMAL(10,2)
- • RAW → VARBINARY
- • NVARCHAR2 → NVARCHAR
Fonctions SQL différentes
De nombreuses fonctions SQL ont des noms ou des syntaxes différentes entre Oracle et MySQL :
|| vs MySQL : CONCAT()SUBSTR() vs MySQL : SUBSTRING()SYSDATE vs MySQL : NOW()NVL() vs MySQL : IFNULL() ou COALESCE()Syntaxe OUTER JOIN
Oracle utilise la notation (+) pour les jointures externes, qui n'existe pas dans MySQL. Il faut convertir vers la syntaxe ANSI standard.
Oracle (notation (+)) :
SELECT * FROM users u, orders o
WHERE u.id = o.user_id(+);MySQL (ANSI standard) :
SELECT * FROM users u
LEFT JOIN orders o ON u.id = o.user_id;Outils pour faciliter la migration
Heureusement, des outils existent pour faciliter cette tâche complexe.
MySQL Workbench
L'outil officiel de MySQL propose un assistant de migration qui peut se connecter à Oracle et transférer le schéma et les données.
✓ Gratuit et officiel
Oracle SQL Developer
Ironiquement, Oracle fournit un outil qui peut exporter vers MySQL. Il génère des scripts de migration du schéma.
✓ Export de schémas complets
Scripts personnalisés
Pour des besoins spécifiques, développer ses propres scripts Python ou Perl avec DBI/DBD peut offrir plus de contrôle.
✓ Maximum de flexibilité
AWS DMS
Si vous migrez vers le cloud, AWS Database Migration Service peut gérer la migration continue avec un temps d'arrêt minimal.
✓ Migration en continu
Bonnes pratiques pour une migration réussie
Testez, testez, testez !
Créez un environnement de test complet et validez chaque fonctionnalité de votre application avant de passer en production.
Documentez tout
Gardez une trace de toutes les modifications apportées au code et au schéma. Cela facilitera le débogage et la maintenance future.
Optimisez pour MySQL
Ne vous contentez pas de traduire : profitez de la migration pour optimiser vos requêtes et votre schéma selon les bonnes pratiques MySQL.
Planifiez la migration des données
Pour les grosses bases de données, prévoyez une stratégie de migration progressive ou une fenêtre de maintenance suffisante.
Surveillez les performances
Après la migration, surveillez attentivement les performances. Certaines requêtes peuvent nécessiter des ajustements ou de nouveaux index.
Conclusion
La migration d'Oracle vers MySQL peut représenter des économies substantielles pour votre entreprise, tout en maintenant des performances excellentes pour la plupart des applications.
Bien que le processus demande du temps et de la rigueur, les bénéfices financiers et la flexibilité gagnée en valent largement la peine. N'hésitez pas à vous faire accompagner par des experts pour garantir le succès de votre migration.