Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je suis débutant en PosgreSQL et je voudrais effectuer une migration automatique d’une application d’Oracle vers PostgreSQL. L’application a été développée en java avec WebObject, et utilise plusieurs fonctions, procédures, triggers,… implémentés dans Oracle. La base Oracle contient environ 500 tables et plus de 200 fonctions, procédures, triggers, etc.… d’où la nécessité d’une automatisation au max. Mon travail dans un premier temps consiste à réaliser une étude de faisabilité de la migration et de proposer des solutions.
Des études ont été menées dessus en 2008 par des étudiants qui ont conclus d’OraToPg n’était pas encore près pour une telle migration.
• Existerait-il d’autres outils de migration fiable ?
• Quelles sont les difficultés généralement rencontrées dans un tel exercice ?
• Quelles pourraient être les étapes d’une telle migration ?
• Pourrais-je avoir des documents d’expériences de migration ?
Merci
Hors ligne
Bonjour,
Pour la réécriture du PL, il n'existe pas d'autre outil approprié que le cerveau humain à ce jour, à ma connaissance : le langage PL d'Oracle et celui de PostgreSQL, même s'ils sont assez proches sur le principe (syntaxes héritées d'Ada), ont quand même de nombreuses différences, principalement au niveau de l'absence de nombreux modules propriétaires Oracle sous PostgreSQL (par exemple tout ce qui permet de générer des fichiers en PL, ou les autonomous transactions). Il y a aussi quelques pièges, comme le comportement des blocs BEGIN/EXCEPTION/END, qui ne se comportent pas exactement de façon identique.
Ora2Pg est au point, pour la migration des données. Pour la réécriture du PL, il y a des choses de faites, mais je doute qu'elles soient suffisantes, surtout si vous avez 200 fonctions.
J'ajouterais aussi, d'expérience pour avoir utilisé de tels outils, que les générateurs de code (par exemple, générer du C à partir d'un autre langage) génèrent un code qui n'est la plupart du temps pas maintenable: il n'est pas fait pour être relu, modifié ou édité, seulement pour être compilé. On se retrouve donc à continuer à développer le code original, et à regénérer le code du nouveau langage à chaque fois, ce qui est un peu contraire à la notion de migration.
Bref, c'est pour vous dire qu'à mon avis, la migration du code n'est pas quelque chose qui est automatisable.
Vous avez sinon la possibilité de partir sur une version propriétaire de PostgreSQL, comme Enterprise DB, qui, elle, a un langage PL compatible avec celui d'Oracle, et évite donc des réécritures. Cette version est payante, mais largement abordable par rapport à Oracle…
Ce n'est que mon avis sur la question, quelqu'un d'autre aurait il une opinion divergente ? 
Marc.
Hors ligne
Ce n'est que mon avis sur la question, quelqu'un d'autre aurait il une opinion divergente ?
Non. +1
En ce qui concerne la migration des données ; il ne devrait pas y avoir de problèmes.
En ce qui concerne le PL ; il faut faire un inventaire du code ; mesurer le nombre de lignes de codes ; inventorier les différents packages Oracle utilisés.
Ensuite ; prendre le temps de recoder quelques fonctions / triggers pour avoir une indication statistique du coût de la migration de la totalité du code.
Hors ligne
Bonjour ,
Merci Marc, merci Herve pour ses éclaircissements. vous me semblez avoir de l'expérience. Je voudrais savoir quelles sont les difficultés qu'on pourrai rencontrer pendant une telle opération? Pourrais-je avoir les étapes détaillées pour la migration? Et si vous avez des expériences en migration, pourriez vous m'en faire part?
Merci
Williams
Hors ligne
Les difficultés sont simples : le langage PL est différent. Le SQL est différent aussi (mais dans une mesure très largement moindre, tant que l'application de départ se cantonne au SQL standard).
C'est comme si vous vouliez réécrire du Pascal en C. Cela demande redéveloppement.
Les choses importantes auxquelles il faut penser sont les suivantes : Vous devez migrer les données et les interfaces. Les données, c'est le plus simple. Les interfaces, cela veut dire réécrire le PL, et les requêtes s'il y en a.
Il se peut aussi que vous ayez à ré-examiner les procédures de maintenance de l'application (procédures de sauvegarde, de restauration, nettoyage, réindexation, etc…).
Marc.
Hors ligne
Au niveau du PL le plus problématique sera l'utilisation des packages ( DBMS_* ) tels que dbms_standard ; dbms_encode ; dbms_url ; dbms_pipe ; dbms_alert ; dbms_output etc. Il existe aussi des packages "UTL_*" comme UTL_FILE.
Personellement ; en ce qui concerne le code ; je commencerais par faire l'inventaire de toutes les utilisations de ces packages.
Hors ligne
Merci mes frères je commencerais par suivre vos conseils.
Dernière modification par tchasp (20/09/2010 15:35:49)
Hors ligne
Pages : 1
