Discussion :

[tchasp]

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

Williams

[SQLpro]

Ne rêvez pas, il n'existe AUCUN outil capable de faire cela....

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 ?

Non et jamais !

• Quelles sont les difficultés généralement rencontrées dans un tel exercice ?

Différence de type de données...
Différence de langage (SQL étant perméable à des spécificités des éditeurs). Donc requêtes à récrire...
Différence de codage dans les fonction, triggers et procédures...
Différence fonctionnelles (par exemple Oracle utilise la récursivité avec un truc spécifique CONNECT BY PRIOR alors que PostGreSQL utilise la voie normative avec les CTE).
Et pour couronner le tout, différence fonctionnelle en matière de niveau d'isolation des transactions....

• Quelles pourraient être les étapes d’une telle migration ?

1) migrer le modèle de la base avec un outil de rétro conception comme Power AMC.
2) récrire toutes les requêtes
3) récrire tous les déclencheurs
4) récrire toutes les fonctions
5) récrire toutes les procédures
6) vérifier le transactionnement
7) tester et livrer en béta version

• Pourrais-je avoir des documents d’expériences de migration ?

Là vous me demandez plusieurs heures de boulot... Que je tarife 200 € HT de l'heure !!!!

Si c'est une grosse application, j'étudierais sérieusement le coût d'une telle opération qui peut s'avérer beaucoup plus cher que de s'offrir quelques licences Oracle. Mais si c'est du long terme, c'est différent.

A +

[estofilo]

A noter que EntrepriseDB vend une version de PostgreSQL nommée "Postgres Plus Advanced Server" orientée vers les migrations Oracle.
Voir (en anglais): http://www.enterprisedb.com/solutions/oramig.do

[tchasp]

Merci Frédéric, merci estofilo pour ses informations et conseils. vous me semblez avoir de l'expérience. je vais commercer par faire un inventaire du code. Connaissez vous des méthodologies pour y parvenir avec un meilleur résultat?

[scheu]

Tu peux aussi rajouter :

- fonctions / syntaxes spécifiques à Oracle qui n'ont pas toujours d'équivalent sur postgresql : decode/coalesce, jointure ouverte (+), rôles-privilèges-grants, types de données large objects, transactions autonomes, ...

- différences de comportement (gestion des transactions, ordre de tri différent selon la casse, gestion différente des NULL, optimiseur et plans d'exécution à recetter, différences de respect de la norme SQL, ...)

Pour migrer le modèle, effectivement un outil de reverse-engeenering est le plus simple.
Pour migrer les données, un outil ETL qui fait ça en one-shot ou un export de chaque table Oracle en fichier plat CSV, puis import dans Postgresql avec l'utilitaire COPY

Si ton appli a au moins 200 fonctions/triggers, ça peut être long et fastidieux (donc cher) de tout réécrire en PL/PgSQL, tester, recetter ... Ca fait partie des coûts cachés d'une migration vers l'open-source

[tchasp]

Merci scheu, j'ajouterai tous cela à mon étude.