Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai des données à transférer d'une base Oracle 10g vers une base Postgresql 8.1.
Si j'ai bien compris, on peut utiliser le module dbi-link pour accéder de la base Oracle à la base Postgresql.
Ou bien on peut se connecter à partir d'Oracle via le driver ODBC.
C'est bien cela?
Sachant que je n'ai pas les droits d'administration sur les machines où sont installées les moteurs (AIX pour Oracle, RHEL 5 pour Postgresql), qu'est-ce qui vous semble le moins compliqué à faire? Ou bien est-ce que j'ai intérêt à faire autrement (export des données + réimport)?
Je dois avoir fini demain soir...
Hors ligne
Je parierais sur export/import.
Guillaume.
Hors ligne
Export ça n'est pas possible : les exports Oracle sont binaires. Enfin il y a du texte à l'intérieur, mais je ne me risquerais pas à les traiter à coup de 'strings' Unix.
Pour ce qui est des dblinks, dans les deux cas, cela sera compliqué : installer le driver ODBC pour PostgreSQL sous AIX promet d'être une galère sans nom.
Installer le driver DBI Perl pour Oracle sera un peu moins compliqué, mais demande quand même l'installation du package DBI et des librairies clientes Oracle. Les dépendances sont d'ailleurs les mêmes que pour Ora2pg. Et que ça soit sous AIX ou Linux, l'installation en temps que simple user risque d'être vraiment compliquée.
S'il s'agit de migrer quelques tables en one-shot, un ETL comme kettle serait peut être plus efficace dans ce contexte ? Pour une bête recopie de quelques tables, c'est vraiment très rapide à mettre en place . Enfin il faut prendre le truc, un etl ça s'apprivoise 
, mais dans un cas simple comme ça, c'est juste lire une table et écrire dans une autre, donc un traitement basique.
Et puis rien à installer sur les serveurs, tout peut se faire du poste client.
Dernière modification par Marc Cousin (15/04/2010 18:30:04)
Marc.
Hors ligne
Quand je disais export, c'est pas par l'outil du même nom, mais par une procédure stockée qui exporte les données en csv...
Hors ligne
Sinon avec un outil Oracle gratuit comme SQL Developper, on peut afficher les données des tables et les exporter directement en format CSV, qu'on peut ensuite réimporter dans Postgresql via COPY
Si tu n'as pas énormément de tables et qu'elles ne sont pas très volumineuses c'est encore le plus rapide, ça évite de devoir faire un développement PL/SQL spécifique
Hors ligne
scheu, cette solution marche correctement si tu as la chance d'avoir au moins les conditions suivantes :
- même schéma au départ et à l'arrivée (il ne faut pas que tu aies une colonne en trop ou en moins)
- possibilité d'immobiliser la base le temps d'exporter tes x tables (si x=100, ça peut agacer les utilisateurs ), et ne pas se planter et avoir besoin de recommencer
- des types pas trop complexes, et pas de problème de locales (séparateurs décimaux, ordres dans les dates, etc…)
Il y a certainement d'autres choses auxquelles je n'ai pas pensé, mais la solution SQL Developper ne me semble valable que pour moins de 10 tables grand maximum. Je ne crois d'ailleurs pas trop en la solution PL/SQL spécifique non plus, toujours à cause des ennuis que peuvent entraîner les formats d'export différents, et le côté un peu perte de temps de 'réparer' le dump avant de le réinjecter (pour corriger les dates, les booleans, etc…)
L'ETL est un peu pénible parce que souvent graphique, un peu fastidieux à mettre en place, mais permet de préparer tout le traitement et l'exécuter assez efficacement le moment venu (après 50 répétitions si nécessaire).
Marc.
Hors ligne
Au fait, merci à tous pour vos conseils. J'ai finalement suivi le conseil de Marc (ETL), et j'ai bien fait je pense. Il y avait une soixantaine de tables à copier, avec des différences de schéma (des colonnes à supprimer), et des conversions de type. On avait oublié de me dire que certaines colonnes des tables de départ ne devaient pas être prises en compte.
J'ai utilisé Pentaho Data Integration (Kettle), et cela m'a pris environ 1 jour (installation, mise en place, test...). Sinon j'aurais fait avec un script bash + une procédure PL/SQL mais je pense que j'y serai encore. En effet il m'aurait fallu écrire toutes les requêtes d'extraction en vérifiant la liste des champs pour chaque table dans Oracle et dans Postgres, alors qu'avec Kettle on a directement la correspondance entre les colonnes de la table de départ et celle d'arrivée. Je ne sais pas ce que cela aurait donné pour l'encodage...
Sinon, juste une question au cas où quelqu'un connaitrait la réponse : quand on utilise COPY pour charger une table, comment doit être représentée la valeur des booléens? (j'ai pas vu cette info sur la page de doc de la commande COPY)
Hors ligne
Dans le format COPY, true est représenté par 't', false par 'f'
Marc.
Hors ligne
Pages : 1
