Dans un monde informatique de plus en plus ouvert aux SGBDR, nous assistons à un nouveau match opposant les bases de données gratuites propriétaires et les bases de données Open Source. Ce match a bien sûr des règles très précises et limitatives dans un marché international où le coût des licences SGBD pèse à lui seul plus de 15 milliards de dollars.
Les bases de données gratuites propriétaires, appelées aussi Express, sont aujourd’hui très prometteuses mais se limitent au niveau des ressources.
Aujourd’hui, les plus grands éditeurs sont entrés en guerre dans cette course au monde libre et présentent des versions gratuites de leurs bases de données. Nous nous sommes intéressés plus particulièrement à Oracle, leader des SGBD sur un marché de plus en plus concurrentiel et à SQL Server s’appuyant plus que jamais sur la technologie Microsoft.
Ces deux ténors proposent des versions complètes, de type « Standard Edition » allégées et gratuites, des moteurs SGBD les plus avancés du moment. Ces éditeurs comptent rallier beaucoup de suffrages.
La seule faiblesse, et de taille, de ces offres basées sur une technologie de pointe aussi bien chez Oracle que chez Microsoft, vient du fait que ces bases sont destinées uniquement aux petites organisations. Il paraît inconcevable de travailler en production pour de plus grandes organisations avec des bases de données ne dépassant pas les 4 giga octets et ayant des performances dégradées du fait de la limitation en CPU et en mémoire. Les offres « gratuites » de Microsoft, Oracle et même Sybase sont, en fait, des produits bridés. Il y a une énorme différence entre un produit bridé et gratuit et un produit illimité et libre (MySQL et PostgreSQL).
C’est pourquoi la solution la plus adéquate actuellement pour limiter les coûts en conservant le maximum de fonctionnalités et de compatibilité est de se tourner vers des bases de données Open Source comme PostgreSQL et MySQL qui exploitent les ressources des machines au maximum de leur capacité.
Cependant, l’actualité autour des SGBD est très vive et les éditeurs sont très offensifs pour conserver leurs parts de marché, en prenant très au sérieux la concurrence du libre. L’acquisition récente par Oracle du moteur de stockage InnoDB de MySQL en est une nouvelle preuve.
Migrer une base existante ?
Si les bases de données Open Source apparaissent bien sûr très attractives pour les nouveaux projets, la question apparaît bien sûr plus complexe lorsqu’il s’agit de migrer une base existante vers une base libre. Car si les bénéfices peuvent être substantiels en terme de coût de support et de maintenance, il convient bien sûr de s’assurer que la migration ne crée aucune dégradation fonctionnelle. Et que le coût du projet reste en deçà des économies potentielles !
Comment migrer en toute sérénité ? Comment industrialiser le processus de migration, aussi bien pour les environnements de qualification et de développement que de production ?
Bull, dans le cadre de son offre de services Open Source Libre Energie, s’est attaché à développer de tels outils et méthodologies de migration vers PostgreSQL et MySQL, en s’appuyant entre autres, pour les migrations Oracle, sur le logiciel libre ora2pg (au développement duquel Bull contribue activement), intégré au sein d’un outil de migration conçu par Bull, OTP.
Un exemple de migration : le projet WEBTEC
Comme cas concret, nous prendrons dans cet article l’exemple de la migration d’un applicatif utilisé par Bull, WEBTEC, qui a été migré avec OTP, d’Oracle vers PostgreSQL.
WEBTEC est un outil de surveillance et de « capacity planning » développé par Bull pour son activité infogérance. Il permet d’avoir une visibilité de la production et d’améliorer la qualité de service et la productivité. Les informations récoltées sont archivées et analysées. L’application concerne les bases de données, systèmes d’exploitation, sauvegardes, systèmes de messageries, réseaux et bases de connaissance. Il permet la remontée quotidienne d’information sur les 24 dernières heures de production. C’est donc un outil au cœur de notre métier d’infogérant.
PostgreSQL est plus proche d’Oracle que MySQL. Il est aussi totalement Open Source. D’où le choix de PostgreSQL pour cette migration, bien que MySQL puisse être bien sûr une alternative attractive dans de nombreux autres cas.
Dans le cadre de cette migration, la base Oracle de production (11Go de données utiles) utilisée par notre applicatif Bull/WEBTEC a tout d’abord été portée avec succès vers PostgreSQL avec l’outil OTP. Les prérequis et le mode de migration sont détaillés en annexe.
L’applicatif, au départ écrit en langage PHP/Oracle, a également été réécrit avec la syntaxe PHP/PostgreSQL. Ce travail fastidieux mais peu compliqué a été nécessaire pour WEBTEC car les pages ont été développées purement pour Oracle avec les requêtes directement dans le code sans passer par exemple par un fichier contenant un pool de requêtes.
Les applicatifs en langage Java sont souvent plus rapides pour cette conversion.
Des tests ont été réalisés sur des plates-formes Linux RedHat et Windows XP, montrant qu’il est également possible de changer le type de plate-forme entre les serveurs source et cible car les fichiers exportés sont de simples fichiers texte.
Un bilan positif
Le résultat de cette migration nous a permis d’une part de valider les mécanismes de transfert et de migration des données et, d’autre part, de limiter les risques de dysfonctionnements applicatifs générés directement ou indirectement par la migration d’Oracle vers PostgreSQL.
Du point de vue fonctionnel, le bilan s’est avéré indéniablement positif :
les types de données utilisés durant les tests ont tous trouvé leurs équivalents dans PostgreSQL ;
les procédures stockées ont été adaptées manuellement vers le langage PL/PgSQL sans difficultés ;
les chargements massifs dans la base Oracle par SqlLoader ont été simplement remplacés par des commandes COPY FROM ;
les objets de type LOB (image, document, etc.) ont été portés sans problème ;
les procédures d’exploitation (sauvegarde, restauration) ont été mises à jour à iso fonctionnalités.
Des tests de performance et de robustesse sur PostgreSQL ont été effectués par le centre de compétences bases de données de Bull (Echirolles), avec des tableaux de synthèse (volumétrie, nombres d’utilisateurs, « best practices ») à la clé.
Le ROI s’est également révélé excellent, le coût des 20 H/J de migration (base de données et applicatif compris) s’avérant bien inférieur aux économies de licence et de support prévues.
Ce retour d’expérience montre qu’il est tout a fait possible d’envisager de se passer de composants propriétaires mais un audit de faisabilité doit être réalisé au préalable pour vérifier la compatibilité entre les applicatifs, les fonctionnalités nécessaires et les composants Open Source disponibles.
Cette migration vient bien sûr enrichir l’expérience et l’offre de Bull de portage vers Open Source : Libre Echange. Pour en savoir plus 
Annexes
Les outils de migration utilisés
Les outils développés par Bull (OTP) pour cette migration sont basés sur le module ora2pg et ont pour objectif d’industrialiser l’utilisation de ce module (traces, souplesse, parallélisme).
Ora2pg, téléchargeable sur http://www.samse.fr/GPL/ora2pg/, est sous licence GPL. Bull contribue activement à son développement.
Le fonctionnement d’Ora2Pg est le suivant :
connexion à une base Oracle ;
découverte automatique de la structure et des objets de la base ;
conversion de la base en syntaxe PostgreSQL ;
export dans une base PostgreSQL.
Liste des éléments SQL exportés :
SCHEMA / NAMESPACE ;
TABLE, VUES ;
CONTRAINTES : Unique, Primary, Foreign key, Check;
INDEX ;
TRIGGER ;
SEQUENCE ;
FONCTIONS, PROCEDURES, PACKAGES ;
DROITS (Grant, Role, User) ;
TABLESPACES (PostgreSQL v.8.x.x).
L’extraction des données de la base Oracle peut se faire sous deux formes :
DATA : une ligne d’INSERT par tuple ;
COPY : bloc de données.
Leur chargement peut se faire de deux façons :
par fichier via la commande psql ;
directement par une connexion à la base PostgreSQL.
Seul les éléments TABLE, INDEX, CONTRAINTES et SEQUENCE sont automatiquement convertis vers PostgreSQL.
Il est nécessaire d’adapter les autres types (VUES, TRIGGER, FONCTIONS, PROCEDURES, PACKAGES et DROITS) manuellement pour PostgreSQL. En effet, le langage PL/SQL d’Oracle est sensiblement différent du PL/PGSQL de PostgreSQL.
Le fonctionnement d’OTP :
OTP est le module qui encapsule et industrialise l’utilisation d’ora2pg. Il permet de migrer les tables d’Oracle vers PostgreSQL étape par étape, chaque étape ayant ses propres fichiers de traces.
De plus, celui-ci permet de paralléliser les étapes d’export et d’import des données en fonction du serveur source et cible (mémoire, nombre de CPU) et de ne créer les contraintes d’intégrité et d’index qu’après import des données (import plus rapide et plus souple).
Ce module est écrit également en langage Perl. Il possède un fichier de configuration unique pour toutes les étapes de la migration.
Les données sont exportées dans un fichier à plat et non directement dans la base PostgreSQL. Ceci permet, en cas de problème au niveau de l’import, de ne pas avoir à recommencer l’étape d’export.
En plus de Perl 5, ora2pg et OTP nécessitent les modules Perl suivants :
DBI ;
DBD : Oracle ;
DBD : Pg (optionnel) ;
Compress : Zlib (optionnel).
Il s’exécute sur toutes les plates-formes supportant Perl, Oracle (client) et PostgreSQL (client).
Les prérequis pour la plate-forme cible
PostgreSQL est disponible sur de nombreux systèmes d’exploitation. Son installation nécessite un certain nombre de prérequis.
Pour les plates-formes UNIX® et Linux® :
GNU make est nécessaire ; les autres programmes make ne devraient pas fonctionner ;
il est nécessaire d'avoir un compilateur C ISO/ANSI. Une version récente de GCC est recommandée mais PostgreSQL est connu pour être compilable avec de nombreux compilateurs de divers vendeurs ;
tar est requis pour déballer la distribution des sources avec soit gzip soit bzip2 ;
La bibliothèque GNU Readline sera utilisée par défaut (sous NetBSD, la bibliothèque libedit est compatible Readline et est utilisée si le fichier libreadline n'est pas trouvé) ;
La bibliothèque de compression zlib sera utilisée par défaut.
Pour les plates-formes Windows :
vous pouvez construire PostgreSQL pour les versions NT de Windows (comme Windows XP et 2003) en utilisant MinGW ;
vous pouvez aussi construire PostgreSQL en utilisant Cygwin (ancienne version de Windows).
Paquetages optionnels :
• pour PERL : bibliothèque libperl partagée et les fichiers d'en-tête ;
• pour Python : Python installé avec les fichiers d'en-tête et le module distutils ;
• pour le langage de procédure PL/Tcl : Tcl doit être installé ;
• pour activer le support de langage natif (NLS) : besoin d'une implémentation de l'API Gettext. Certains systèmes d'exploitation l'ont intégré (par exemple, Linux, NetBSD, Solaris) ;
• pour authentification ou chiffrement : besoin de Kerberos, OpenSSL ou PAM ;
• si compilation à partir d'une arborescence CVS : besoin des paquetages GNU Flex 2.5.4 et Bison 1.875 ou postérieur.
La liste des fonctionnalités PostgreSQL compatibles avec Oracle est disponible sur demande, dans le cadre de l'offre Libre Energie™
|
|
|
