Retour d’expérience : Migrer d’Oracle vers PostgreSQL avec Ora2Pg

Pourquoi migrer d’Oracle vers PostgreSQL ?

Le client, grand groupe d'entretien et de réparation automobile, avait pour objectif de réduire ses coûts sur le long terme. PostgreSQL permet également de gagner en flexibilité.

Après avoir étudier ses actifs informatiques (serveurs, bases de données…) en termes de technologies, de volumes et de versions, il a été décidé de migrer dans le cloud AWS. En effet, dans le cas du client, en migrant également vers PostgreSQL, cela permettait de réaliser des économies sur le long terme.

Le contexte de la migration : 14 applications faites maisons

Bien sûr, tout projet de migration commence par une étape d’architecture puis la phase de réalisation de la migration.

L’environnement de production n’a pas changé d’infrastructure pour limiter le risque de la migration (machine physique vers machine physique), les autres environnements ont par contre été déplacés dans le cloud.

Au total, il s’agissait de migrer 14 applications faites maisons d’Oracle vers PostgreSQL, dont plus de 1400 fonctions et procédures pour l’application principale.

Toutes ces applications fonctionnaient sur le même principe : un DAL (Data Access Layer) et des procédures pour chaque appel à la base de données. Aucune requête n’était gérée dans les applications.
De ce fait, il a été souhaité de ne pas toucher aux applications mais uniquement à la partie connexion. Il s’agit d’un cas de figure assez rare pour une migration d’Oracle vers PostgreSQL mais cela a été possible grâce à cette architecture applicative.

L’essentiel du projet de migration consistait en un travail applicatif au niveau de la base de données, à savoir de la réécriture de code, des validations techniques et fonctionnelles ainsi que des validations de performance.

Quelle méthodologie pour migrer d’Oracle vers PostgreSQL ?

Pour correspondre aux différentes caractéristiques du projet, nous avons opté pour une méthodologie résumée en 5 étapes :

• Utilisation d’Ora2Pg, un utilitaire qui permet d’estimer le temps passé pour la migration et qui fait les conversions de la syntaxe Oracle vers PostgreSQL ;
• Réalisation d’un Proof of Concept (PoC) pour migrer une « petite » application représentative vers PostgreSQL ;
• Correction manuelle des fonctions en erreur via des scripts rejouables ;
• Automatisation de certaines corrections nécessaires car les drivers PostgreSQL et Oracle ne fonctionnent pas de la même manière : changement d’un retour de refcursor à un retour d’enregistrement. Il aurait été possible de faire la modification coté applicatif mais le choix a été de reporter le coût de la modification du côté de la base de données ;
• Mise en place de tests automatisés de non-régression pour l’ensemble des procédures.

Exemple de migration d’une application via Ora2Pg

• Initialisation d’un projet Ora2pg ;
• Première migration à blanc de l’application en utilisant Ora2Pg ;
• Corrections des fonctions, procédures, vues et flux qui ne compilent pas et des tables et index en erreur ;
• Tests unitaires automatisés ;
• Correction des fonctions, procédures, vues et flux en erreur ou générant des timeout pour des raisons de performance ;
• Tests de non-régression et de performance   ;
• Correction des problèmes remontés (erreurs non remontées par les tests unitaires, problèmes de performance…) ;
• Pour les applications les plus simples : arrêt de la production puis rejeu de la migration via Ora2Pg ;
• Pour l’application principale : la production est régénérée uniquement avec la structure des tables. Les données non modifiées sont migrées en avance. Le jour de la migration, arrêt de la production, migration des données restantes puis récupération des séquences (via Ora2Pg) et recréation des index et contraintes.

Retour d’expérience sur une migration d’Oracle vers PostgreSQL en utilisant Ora2pg

Nos experts ont listé différents points positifs ou négatifs quant à l’utilisation d’Ora2pg mais aussi des conseils pour migrer plus sereinement d’Oracle vers PostgreSQL.

Il ne s’agit pas de listes exhaustives mais des retours d’expérience issus de la migration réalisée pour notre client spécialiste de la réparation automobile.

Les avantages d’Ora2pg

La migration de données n’a pas posé de problème, et les différentes conversions se sont passées sans problème.

Un nombre significatif de procédures ont pu être converties et fonctionner directement sans modification majeure.

Les limites d’Ora2pg

Ora2Pg n’est pas la panacée. Nous avons notamment été confronté à différentes limites de l’outil : pas de conversion des chaines de caractères, bugs sur des variables se terminant par « return », environ 25% de corrections manuelles (plus ou moins complexes) sur les procédures (par exemple, l’instruction MERGE doit être transformée en INSERT ON CONFLICT DO UPDATE).

Ora2Pg ne modifie que les données et le code en base. Il ne touche pas l’applicatif ou les flux en dehors de la base. Dans notre cas, les flux n’étaient pas trop nombreux (environ 50) mais leur migration a presque été aussi couteuse en temps que celle de la base de données.

Les points d’attention quand on passe d’Oracle à PostgreSQL

Sans surprise, certaines fonctionnalités d’Oracle n’existent tout simplement pas dans PostgreSQL. Il faut l’envisager en amont. Dans notre cas, cela n’a concerné qu’un nombre faible de procédures : 4 dont 2 qui ne servaient plus.

Les spécificités de PostgreSQL

Chaque technologie a ses propres spécificités. Petit tour d’horizon des cas rencontrés :

• Un des problèmes les plus fréquents est que PostgreSQL est très strict sur les typages, on ne peut pas assigner un char dans un varchar ou un integer dans un numeric… Ce qui peut provoquer des erreurs assez nombreuses ;
• Autre problématique du au typage fort dans PostgreSQL : on a du ajouter un cast pour toutes les occurrences de clock_timestamp() (equivalent sysdate) qui par défaut est un timestamp with timezone alors qu’il était souhaité un timestamp without timezone ;
• Autre problème de typage, un type par défaut est donné pour les constantes dans les clauses select qui n’est pas toujours celui souhaité, donc on est également obligé d’ajouter des casts à ce niveau-là (par exemple null est du texte par défaut…) ;
• Il y a également eu des problèmes de performances sur les requêtes complexes (en particulier les flux/batches). Le planificateur de requête PostgreSQL est moins performant que celui d’Oracle en particulier pour tout ce qui concerne l’intégration des vues en lignes dans la requête. En outre pas de hint, on est donc obligé de jouer avec des fonctions sur les colonnes pour désactiver certains index, etc… ;
• Le client a fait le choix d’utiliser uniquement le type numeric pour les nombres, afin de simplifier la migration. Il est possible que ce ne soit pas le meilleur choix (performance sur les opérations sur ce type de champ moins bonne que sur les integers) ;
• Il n’existe pas de packages dans PostgreSQL. Les packages sont transformés en schémas qui contiennent les fonctions et les procédures : on doit remplacer toutes les variables /constantes globales ;
• Les tests et correction de performances sur les flux peuvent demander beaucoup de temps (par exemple, 6 jours sur un seul flux) ;
• En passant sur PostgreSQL, il fallait adapter la solution de supervision, il a donc fallu chercher des outils permettant de remonter les requêtes les plus consommatrices (dynatrace / datasentinel / pganalyze).

Quelques conseils pour une migrer plus aisément

3 conseils partagés par notre expert, quant à l’utilisation Ora2Pg :

• Les tests unitaires de fonctionnalités ont été mis en place pour l’application principale, ce qui a permis d’identifier assez rapidement les erreurs suite à la migration initiale via Ora2Pg ;
• Il est important de prévoir des tests de performances sur les fonctionnalités essentielles de l’application. En effet, dans notre cas, des différences significatives ont pu être trouvées et ainsi corrigées ;
• Avec Ora2Pg, il est possible d’effectuer la copie des données, dont une partie en avance, si on est capable de définir les données non modifiées dans la base de données.

En conclusion, faut-il utiliser Ora2Pg ?

Pour les applications les plus simples, Ora2Pg a fait 80% à 100% du travail et il n’y a eu quasiment aucun problème. Cependant, la migration de l’application principale a été reportée plusieurs fois afin de réaliser les tests de performance et de non-régression.

Concernant la migration de la plus grosse application, certaines fonctionnalités ont fortement chargé la base quelques heures suivant la migration. De plus, le nombre de sessions sur pgpool (proxy de connexion) n’était pas suffisant, ce qui a occasionné des blocages. Finalement, tous les problèmes critiques ont pu être réglés rapidement et les quelques problèmes de performance significatifs ont été réglés au cours de la première journée.

Les performances de l’application et des flux sur PostgreSQL sont en accord avec les attentes du client. Cela ne signifie pas que tout est aussi rapide que sur Oracle. En effet, certains flux ou appels de procédures/fonctions sont plus lents (jusqu’à 50% plus lents), d’autres sont plus rapides naturellement ou après optimisation (jusqu’à 30% plus rapides). Néanmoins, globalement les performances sont équilibrées entre l’ancienne infrastructure et la nouvelle.

En conclusion, Ora2Pg a été un outil qui nous a permis de mener cette migration à bien, mais il a fallu impliquer différents collègues pour faire de cette migration une réussite. Également, l’outil aide mais ne fait pas tout et un effort particulier a été investi pour permettre de faire des tests unitaires / de performance automatisés afin de faciliter la migration.