Babelfish Compass : Facilitez la migration de SQL Server vers Babelfish for PostgreSQL

Bachir
4 octobre 2024
Suite au dernier article où nous avons exploré Babelfish for PostgreSQL, nous allons cette fois-ci pencher sur Babelfish Compass, un outil essentiel qui simplifie la migration.

Introduction

Babelfish Compass (BC) est un outil Open Source qui identifie les corrections nécessaires pour qu’un script T-SQL, SQL/DDL puisse être migré vers Babelfish for Postgres. C’est d’ailleurs la première étape à réaliser lorsque l’on envisage une telle migration. En effet, grâce à cet outil, il est possible d’évaluer la charge de travail liée à la récriture des Features incompatibles. C’est un outil Standalone, On-Premise et ne dépend pas techniquement du projet Babelfish for Postgres.

Fonctionnement de Babelfish Compass

BC scanne et analyse le schémas des bases de données SQL Server, y compris les tables, les vues, les fonctions, les procédures stockées et les triggers. Il vérifie la structure et les propriété de ces objets pour évaluer leur compatibilité avec Babelfish.

BC inspecte les scripts et commandes T-SQL afin d’identifier les fonctionnalité propre à SQL Server qui ne sont pas compatible avec Babelfish. Il signale les différences syntaxiques et les ajustements à faire pour rendre le code compatible.

Après avoir analysé notre DDL, BC génère un rapport détaillé en format html et txt. Dans ce rapport, nous pouvons trouver plusieurs sections plus ou moins détaillées (nous allons y revenir pour un cas pratique).

Ce qui nous intéresse le plus sont les fonctionnalités, et celles-ci sont groupées en plusieurs sections :

  • Supported : fonctionnalités compatibles avec Babelfish
  • Not supported : incompatibles et ont trois niveaux de complexité : Low, Medium, et High
  • Review Semantic : non gérées par BC et une analyse s’impose pour déterminer si des modifications sont nécessaires
  • Reviw Performance : fonctionnalités incluant un aspect lié à la performance
  • Review Manually : ne peuvent pas être déterminées par BC et une vérification manuelle est requise
  • Ignored : ignorées et non analysées par BC
  • Rewritten : fonctionnalités réécrites par BC et désormais compatibles

Et enfin, un tableau csv est également généré, contenant une estimation de la charge de travail requise pour rentre le code compatible avec Babelfish.

Utilisation de Babelfish Compass

Prérequis :

BC a été développé en Java et peut être installé sur Linux, Max, et Windows. Il est nécessaire d’avoir un environnement de runtime Java (JRE). C’est le seul prérequis si nous considérons que nous avons déjà des scripts/DDL de nos BDD à migrer, ou SSMS installé sur notre machine.

Checker la version de Java

Installation :

A chaque nouvelle fonctionnalité introduite dans une Release de Babelfish, une version correspondante de BC est également publiée. Il est donc important de choisir la bonne version de BC en fonction du serveur de base de données installé.

A noter qu’il faut aller dans les Releases et de télécharger le fichier zip et non pas le code source. Lien du GitHub : https://github.com/babelfish-for-postgresql/babelfish_compass/releases

Au moment ou j’écris cet article, la dernière version de BC est la v2024-07.

En vrai, il n’y pas d’installation proprement dite de l’outil, il suffit de télécharger le fichier zip depuis le repository GitHub du projet et de l’extraire dans un dossier de travail. Nous pouvons tester la bonne exécution de BC en se rendant dans le répertoire de travail et de taper la commande : .\BabelfishCompass.bat -help

Tester Babelfish Compass

A noter qu’il n’est pas conseillé de définir le dossier « C:\Users\[mom_utilisateur] » comme répertoire de travail, car c’est l’emplacement par défaut où BC génère ses rapports. Dans la version actuelle de l’outil, il n’est pas de possible de changer ce chemin via une configuration directe. La seule façon de le changer serait de modifier le chemin du répertoire personnel de l’utilisateur dans Windows, ce qui n’est pas très pratique. BC détermine ce chemin en utilisant la commande Java System.getProperty("user.home").

Etude de cas

Nous allons à présent passer à BC un script d’une BDD, ayant le chemin « ..\MSSQL_DDL\babelfish_compass_db.sql », en spécifiant quelques paramètres. Je détaille le choix de ces paramètres un peu plus loin dans l’article.

Lancer l’analyse en ligne de commande

Nous pouvons trouver plusieurs métriques comme le montre la capture ci-dessous. 3 secondes ont suffit à BC pour scanner et analyser une base de données de 3407 lignes :

Logs du Babelfish Compass

Le dossier de destination s’ouvre à la fin de l’exécution et contient plusieurs fichiers et dossiers :

Dossier résultant d’une analyse de Babelfish Compass

Captured : contient une copie du script original SQL (DDL).

Imported : contient les fonctionnalités, objets, et options identifiés lors de l’analyse

Log : contient les logs comme son nom l’indique

Rewritten : contient le script SQL original, ainsi que des sections réécrites par BC et désormais compatibles.

Et enfin, comme mentionné précédemment, le rapport aux formats html et txt, ainsi que le rapport d’estimation de la charge de travail pour la réécriture des Features non compatibles.

Dans notre exemple, l’option « -reportoption » permet la définition des flags :

  • xref (cross-references): utilisé pour générer un hyperlien qui renvoi au code concerné par la Feature en question
    • Pour éviter que cela ne se produise à la fois pour les objets et les fonctionnalités, ce qui pourrait ralentir l’analyse, j’ai choisi de me limiter aux objets seulement.
  • rewrite : permet à BC de traduire certaines fonctionnalité natives de SQL Server en T-SQL compréhensible par Babelfish.
    • Pour une base de données plus complexe et/ou volumineuse, il est conseiller, afin d’éviter un temps d’analyse trop long, de ne pas utiliser ce flag directement. Il est plutôt préférable d’utiliser d’abord le flag -analyse pour que BC identifie les éléments à réécrire, puis dans un second temps, utiliser les deux flag -analyse et -rewrite simultanément.

Il existe évidemment de nombreux autres flags et paramètres à passer pour personnaliser l’analyse.

Le rapport Compass :

Dans le rapport html, nous pouvons commencer par regarder la section « Executive Summury » pour nous faire une idée macro sur notre BDD. A noter que la BDD ne comprend pas des traitements complexes tels que des traitements XML ou des données géospatiales, mais comporte néanmoins des opérations et adaptées à des besoins standards.

Executive Summury

Nous pouvons immédiatement être interpelés par le faible nombre de Features incompatibles. Seulement 137 sur 2389, soit 5,7%. Parmi ces 137, seules 46 sont uniques. De plus, seulement 5 d’entre elles ont la complexité « high ».

La section « Assessment Summary » détaille un peu plus l’analyse de BC. Nous pouvons y trouver des informations telles que le nombre de DDL en entrée, le nombre total de fonctionnalités, ainsi que leur classification (Supported, Not Supported, etc.).

Assessment Summary

Après avoir examiné les différents résumés de l’analyse, nous allons nous intéresser à quelques exemples de classification des Features.

  • Not Supported

Ici nous prenons l’exemple de la reconstruction des index qui n’est pas supportée par Babelfish for PostgreSQL. Une fonctionnalité qu’il faudra réécrire dans Postgres.

ALTER INDEX Not Supported

Pour ce faire dans Babelfish, nous pouvons utiliser la clause REINDEX :

REINDEX dans PostgreSQL et Babelfish

  • Review Manually

Ici il s’agit des procédures stockées systèmes. sys.sp_db_vardecimal_storage_format permet de stocker les colonnes de de type DECIMAL ou NUMERIC de manière plus compacte si des valeurs n’utilisent pas toute la largeur maximale de la colonne.

Procédures stockées à revoir manuellement

Il n’est pas nécessaire de l’adapter dans Postgres car ce dernier utilise déjà un format de stockage variable. C’est-à-dire que les valeurs utilisent uniquement l’espace nécessaire pour stocker la précision et l’échelle spécifiée.

  • Review Semantics

Dans SQL Server, nous pouvons, avec la clause WITH SCHEMABINDING, avoir la main sur la modification ou la suppression des tables référencées par une vue.

WITH SCHEMABINDING est par défaut dans Babelfish

Une vue qui est créée sans WITH SCHEMABINDING dans SQL Server sera créée dans PostgreSQL comme si elle avait été créée avec WITH SCHEMABINDING. Cela signifie qu'une table dépendante de cette vue ne pourra pas être supprimée ou modifiée tant que la vue existe.

  • Review Performance

Un exemple de performance est celui de la persistance ou non d’un colonnes calculée. Dans SQL Server, une colonne calculé peut être définie comme persistante (la valeur de cette colonne calculée est physiquement stockée) ou non persistante (cette valeur n’est jamais stockée et elle est recalculée à chaque nouvelle requête).

Performances liées aux colonnes calculées

Avec Babelfish et Postgres, la colonne calculée dans la DDL est non persistante, mais lors de la migration vers PostgreSQL, elle sera tout de même créée comme persistante.

  • Ignored

Concerne généralement des fonctions systèmes propre à SQL Server.

Exemple de Features ignorées

  • Rewritten

Dans notre exemple, BC a réécrit la clause MERGE par les clauses INSERT et UPDATE. Nous pouvons retrouver le script récrit dans la nouvelle DDL dans le dossier Rewritten.

MERGE réécrit avec un INSERT et un UPDATE

Avantages de Babelfish Compass

Nombreux sont les avantages de BC, et nous pouvons citer :

  • BC aide grandement lors d’une migration. Il examine automatiquement les schémas de base de données et identifie les éléments qui peuvent ne pas être compatibles avec Postgres, nous évitant ainsi de vérifier les DDL ligne par ligne, ce qui présente un gain de temps considérable.
  • Des propositions d’adaptation de code sont parfois proposées par BC, nous orientant vers les ajustements nécessaires.
  • Comme Babelfish for PostreSQL, BC n’est pas compatible avec toutes les fonctionnalités de SQL Server et ne nous fournit pas toujours une analyse claire sur celles-ci. Pour y remédier, il est possible de personnaliser le fichier de configuration « BabelfishCompassUser.cfg » afin de classifier les Features en fonction de séniorité de l’équipe. La même chose peut se faire également dans la définition des niveaux de complexité de ces Features et estimer le temps nécessaire à un développeur (selon son expérience) pour les adapter. La documentation officielle recommande que ce travail soit réalisé par un expert pour une analyse plus précise.
  • L’outil fonctionne avec Linux, Mac, et Windows, et il est facile à installer et utiliser.

Conseils pour réussir une migration

Lors d’une migration de SQL Server vers Babelfish for PostgreSQL, il est essentiel de commencer par une étape de reverse engineering en générant le DDL des bases à migrer, puis de les analyser avec BC. C’est ce dernier qui nous aidera à décider si la migration peut être lancée, en fonction de la complexité et du nombre d’objets non compatibles.

Pour éviter une perte de temps lors du transfert de données et pendant le scanne de BC, il est conseiller de réaliser cet exercice uniquement sur la structure des BDD, et non pas sur les données.

Conclusion

Babeflish Compass est un outil simple mais puissant, et essentiel pour les entreprises cherchant à migrer des bases de données SQL Server vers Babelfish for PostgreSQL. Il facilite l’analyse de milliers/millions de lignes de code SQL, permettant aux développeurs de gagner du temps en évitant la lecture manuelle des DDL existants. Grâce à quoi les équipes peuvent se concentrer sur les ajustements à faire. BC aide ainsi à planification de la migration en identifiant les points critiques et en avant les éléments complexes.

Articles similaires

Aucun article

career block background image

Vous souhaitez nous rejoindre ?

Rendez-vous sur notre site carrière pour accéder à toutes nos offres

Microsoft Partner
Databricks Partner
Great Place To Work
Microsoft Partner
Databricks Partner
Great Place To Work
Microsoft Partner
Databricks Partner
Great Place To Work
Microsoft Partner
Databricks Partner
Great Place To Work