Vous n'êtes pas identifié(e).
Bonjour,
Je dois étudier la migration de Oracle 9 vers PostgresSQL 8. Il faut migrer les structures, données et traitements PL/SQL. Ora2pg permet de le faire.
Si vous avez déjà réalisé cette opération à combien estimez-vous
-le gain apporté par Ora2pg pour chaque type d’élément à migrer (structure, donnée et PLSQL)
o par rapport à une migration manuelle
o par rapport à un à retro-engineering (Power AMC) suivi d’une génération du script SQL
Quelles sont les limites l'outil en dehors des vues matérialisées et des tables partitionnées ?
Quelles est sa performance dans la migration du code PL/SQL ? Je suppose qu'il reste des retouches manuelles à apporter dans le code PGSQL obtenu.
Merci d'avance pour vos réponses
Putchhat
Hors ligne
le gain apporté par Ora2pg pour chaque type d’élément à migrer (structure, donnée et PLSQL)
ora2pg crée lui-même le schéma, ce qui est bien plus rapide que de le faire manuellement. Pour les données, il est assez lent mais intéressant malgré tout. Par contre, pour la partie des procédures stockées, je ne l'ai jamais utilisé et il me semble préférable actuellement de le faire manuellement.
o par rapport à une migration manuelle
Tout dépend de ce qu'on appelle manuel 
Pour rester sérieux, je pense qu'il vaut mieux utiliser ora2pg, il sera bien plus rapide.
o par rapport à un à retro-engineering (Power AMC) suivi d’une génération du script SQL
Ça permet de s'assurer que le code généré est compatible avec PostgreSQL. J'ai moyennement confiance dans les outils propriétaires qui ont eu assez de mal à venir à PostgreSQL.
Quelles sont les limites l'outil en dehors des vues matérialisées et des tables partitionnées ?
Les tables partitionnées sont gérées par la dernière version d'ora2pg. Les vues matérialisées ne sont pas disponibles en natif sur PostgreSQL, donc ce n'est pas une limite d'ora2pg.
Quelles est sa performance dans la migration du code PL/SQL ? Je suppose qu'il reste des retouches manuelles à apporter dans le code PGSQL obtenu.
À ma connaissance, ce n'est pas le point fort d'ora2pg. Néanmoins, n'ayant pas utilisé cette fonctionnalité, je laisse la parole aux autres pour mieux répondre à cette question.
Guillaume.
Hors ligne
Pour revenir sur le premier point, pour les performances sur la migration de données, c'est acceptable pour du one-shot de petite base (jusqu'à 5 Go je dirais, mais ça dépend évidemment des contraintes(. Par contre si il s'agit de migrer fréquemment de gros volumes de données, utilisez plutôt un ETL.
Pour les migrations de PL, les langages de chaque moteur sont assez proches, mais suffisamment différents pour que la migration automatique ne soit pas une bonne solution. Rien que la gestion des blocs est légèrement différente entre les deux bases (rollback implicite d'un bloc begin/end dans PlPGSQL, ce qui n'est pas le cas sous Oracle si je me rapelle bien)
Marc.
Hors ligne
Merci pour vos réponses.
Il s'agit bien d'une migration one shot. Par contre la base fait actuellement 17 Go. Quelle est l'ordre de grandeur pour importer cette quantité de données si vous avez une idée ? Plutôt 1h ou 10h ? Ce point m'inquîète.
Hors ligne
Je pense que vous serez entre les 2, peut être plus près des 10h, mais ça dépend de beaucoup de paramètres, comme la puissance des serveurs, mais aussi la latence du réseau.
Marc.
Hors ligne
