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. J'ai plusieurs exemples en tête d'infra ou de soft totalement overkill par rapport à l'application et au trafic réel, mais je ne vais pas m’étendre à ce propos, ça sera l’occasion d’un autre article.
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 :
- Des tables
- Des VUES (Tous les SGBDR sérieux en proposent en standard de mémoire.)
- 3 procédure stockées (Ça devient un peu plus chiant, surtout pour des histoires de performances, on verra ça plus tard.)
- Et rien que du classique : Indexes (BTREE et un FULLTEXT), des auto-increment (donc sous Oracle, des triggers et des séquences.)
- Les types de données exotiques (JSON, XML, columns…)
Ouf ! Pas de trucs vraiment chiants, du genre : vues matérialisées, partitions, DBLINK, réplication et autres joyeusetés.
La conclusion est simple : ce projet ne nécessitait absolument pas Oracle pour tourner (je pondère cette phrase plus loin), pas de configuration exotique et complexe pour répondre à des problèmes de performance tricky, aucune des options "utiles" de Oracle utilisée (comme les Vues Matérialisées).
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 de 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).