La migration de base de données consiste à transférer les données d’un Système de Gestion de Base de Données (SGBD) à un autre. Il ne s’agit pas ici d’une simple mise à jour logiciel de son SGBD mais bien de changer de produit pour son SGBD par exemple remplacer Oracle par PostgreSQL.
Plusieurs raisons peuvent entraîner un changement de SGBD pour Alfresco, la plupart du temps c’est la nécessité de devoir suivre les pré-requis logiciels lors d’une migration de l’application. En effet, pour des raisons de coût de licence ou des raisons techniques, il peut être difficile pour les organisations de devoir mettre à jour leur SGBD au sein de leur système d’information lors de la migration qui font alors le choix d’un SGBD nécessitant un coût de licence moindre par exemple.
La procédure de migration de SGBD que nous mettons en œuvre lors de nos projets se déroule selon les étapes que nous allons détailler ci-après. Lors de la procédure, il faut prendre en compte le temps d’indisponibilité de l’application. Il est donc recommandé de faire un test de migration sur un environnement de test disposant d’une copie des données de production afin de mesurer ce temps d’indisponibilité et de vérifier l’intégrité des données consécutive à l’opération pour effectuer d’éventuels ajustements.
La première étape consiste à créer les tables de la base de données sans contrainte, ni index dans le SGBD cible. Pour créer ces tables on peut soit récupérer les scripts fournis avec l’application en retirant les contraintes soit installer Alfresco à vide avec le SGBD cible et faire un export des tables uniquement. Si le SGBD cible est PostgreSQL, on peut créer un script de création des tables du schéma d’Alfresco avec la commande pg_dump avec l’option -s (export du schéma de base de données) puis en ne conservant que les requêtes de création de table.
La seconde étape est la plus délicate car elle va consister à transférer les lignes contenues dans les tables du SGBD source dans les tables du SGBD cible. En effet, certaines données devront être adaptées au nouveau système comme les chaînes de caractère ou les données stockées sous forme binaire comme les BLOB. Il existe plusieurs étapes pour réaliser ce transfert de données, on peut utiliser un ETL (Extract, Tansform, Load) ou un outil dédié.
Avant de commencer l’étape de transfert de données de la migration du SGBD de la GED Alfresco, il est nécessaire d’analyser le schéma de la base de données de l’application du côté du SGBD source et du SGBD cible afin d’en noter toute les différences en terme de type de colonne entre les deux. Par exemple, quand le SGBD source est MySQL les données booléennes sont stockées dans des colonnes de type TINYINT et si le SGBD cible est PostgreSQL ces données sont stockées dans des colonnes de type BOOLEAN. Il y aura donc une conversion de données à régler dans l’outils choisi, quel qu’il soit, pour l’opération de transfert car il ne le fera pas automatiquement.
Plusieurs critères sont à prendre en compte pour le choix de l’outil utilisé pour le transfert : le produit utilisé pour le SGBD source et celui de la cible, le coût car certains outils sont soumis à des licences payantes, le temps d’indisponibilité de l’application lors de la procédure de migration car le transfert de données est l’étape la plus longue.
La troisième va consister à rétablir les contraintes et de construire les index de la base de données. De la même manière que pour les tables, on peut récupérer les requêtes de création de contraintes et d’index dns les scripts fournis dans l’application ou en les exportant d’une base de données de l’application installée à vide avec le SGBD cible.
La dernière étape est la configuration de l’application pour qu’elle puisse se connecter à son nouveau SGBD. Pour cette étape, il faut penser à installer le pilote JDBC correspondant au produit et à la version du SGBD cible et à la version de Java d’Alfresco.
Si la migration du SGBD est un succès l’application démarrera sans problème et il ne restera plus qu’à effectuer des tests pour vérifier que toutes fonctionnalités de la GED sont opérationnelles.
En cas d’échec, l’application génère des fichiers de log qui indiquent ce qui ne va pas dans la base de données et permettent de faire les ajustements nécessaires dans la procédure qu’il faudra dérouler à nouveau depuis le début. Si l’application démarre et que les tests fonctionnels ne donnent pas satisfaction, il faut utiliser le mécanisme de validation de schéma de base de données intégré dans l’application (https://docs.alfresco.com/5.2/concepts/schema-diff-tool-validation.html) qui indiquera dans les fichiers de log ce qu’il faut modifier dans la procédure.
Lors des différents projets de migration menés par AtolCD, les différents SGBD sources ont été MySQL, Oracle et SQLServer vers le SGBD PostgreSQL et les outils de transfert ont été l’ETL PDI (Pentaho Data Integration anciennement Kettle) et ora2pg (http://ora2pg.darold.net/).
Laisser un commentaire