Migrer de Oracle à Postgre en automatisant le processus !

Migrer de Oracle à Postgre en automatisant le processus, au forfait ! De nombreuses entreprises quittent Oracle pour PostgreSQL   Oracle Database a la réputation d'être coûteuse en termes de licences et de support. Cette politique de tarification peut rendre Oracle moins attrayante pour certaines entreprises. Bloomberg note une baisse des ventes de nouvelles licences chez Oracle. Baisse qui se perpétue depuis 7 trimestres.    En face, on a la base de données PostgreSQL, qui est gratuite, que l’on peut modifier et distribuer, qui a la réputation d’être fiable et stable, avec une bonne gestion des transactions... Tous ces éléments la rendent appropriée pour des applications critiques où la cohérence des données est essentielle. PostgreSQL prend en plus en charge une grande variété de types de données, y compris des types géospatiaux, JSON, etc., ce qui la rend adaptée à la manipulation de données complexes et variées.     Postgre est maintenant la 4ème base de données la plus utilisée dans le monde, avec des taux de croissance importants.   Mais cela reste un mouvement difficile à impulser   Selon Carl Olofson, vice-président de la recherche chez IDC, « Il y a un certain nombre d'utilisateurs d'Oracle qui aimeraient essayer PostgreSQL pour au moins une partie de leur charge de travail, mais qui sont découragés par le risque et le coût de la conversion ». Il faut dire que le PL/SQL, le langage procédural de Oracle a commencé à être utilisé en 1991. C'est le langage procédural le plus présent dans le monde ! Il offre la possibilité d'écrire des fonctions complexes de manipulation de données sans recourir à un langage tiers. Comme c’est un langage de requêtes, il permet de faire des scripts assez complexes : fonctions, procédures, triggers, apex, etc. Le PL/SQL n’est pas migrable tel quel vers Postgre. En tous les cas, pas simplement. Ces projets de migrations sont souvent des projets longs et coûteux, et parfois des échecs.    Mais pas forcément .   Nous avons développé une méthodologie éprouvée, en 2 étapes, pour faire mécaniquement de cette migration un succès, de façon forfaitaire lorsque la DB Oracle est essentiellement utilisée comme entrepôt de données avec des chaînes en PL.   Etape #1 : Simplifier le système en source L’analyse des logs par {openAudit}, notre logiciel, permet de détecter l’information qui passe dans les outils de dataviz et dans l’ensemble des queries (JDBC, ODBC...). Le data lineage de {openAudit}, en remontant tous les flux qui génèrent un usage réel, permet de définir les pans du Système d’Information utiles vs inutiles. Il devient possible d’opérer des décommissionnements massifs en amont de la migration. L’introspection fine des flux dans les bases de données permet à {openAudit} de factoriser le code. Zoom in / Zoom out dans un Système d'Information Etape #2 : migrer techniquement d'Oracle vers PostgreSQL {openAudit} va « parser » le PL/SQL, il va décomposer toute la complexité du code grâce à une grammaire permettant des analyses exhaustives et ultra granulaires. Toutes les subtilités du PL/SQL vont être prises en considération.  {openAudit} en déduit la cinématique d’ensemble et l’intelligence, qui sera reconstruite dans un arbre algorithmique agnostique (ce pourrait être du simple Scratch). Sur cette base, {openAudit}  va produire du  SQL standard. Puis l’intelligence va être reconstruite a minima dans le PgSQL par {openAudit}. Certains traitements complexes, non reproductibles en SQL simple, seront pilotés par un exécutable NodeJS. Typiquement les curseurs « Boucle For », les variables, le code conditionnel « If Else », les « Switchs », les appels à procédure, etc.    Eventuellement, de nouveaux mécanismes d'orchestration peuvent être mis en place pour déconstruire les curseurs de curseurs (les boucles de boucles), ou pour optimiser les chaînes de transformation*. Ainsi, de façon générale, il est possible de décommissionner les patrimoines Oracle et d’en reproduire toute l’intelligence dans PostreSQL de façon extrêmement efficace.    Nous nous engageons : les migrations sont opérées au forfait. *Il y quelques limitations : Les procédures unitaires appelées par du code externe ou des triggers, peuvent faire l’objet de réponses adhoc.