Bonjour,

Ora2Pg fait principalement de la migration de données "oneshot" ce qui effectivement nécessite une interruption de l'application. En terme de vitesse de migration de données, Ora2Pg n'a rien a envier aux meilleurs ETL, c'est une question de nombre de CPU à disposition. Mais en ce qui concerne la possibilité de faire de l'incrémental, les ETL ont plus d'une longueur d'avance. Cependant il existe une fonctionnalité dans Ora2Pg permettant de faire de l'incrémental. Elle est encore en développement mais elle ne demande qu'à être finalisée. Cette fonctionnalité développée par Sebastian Albert peut être activée grâce à la directive de configuration DATADIFF, reportez vous à la documentation pour plus de détail. Personnellement je ne l'ai pas encore vraiment utilisée car l'interruption de service peut être minimisée par d'autres moyens, notamment le chargement à posteriori des données "non vivantes" (avec la directive de configuration WHERE vous pouvez appliquez un filtre aux données à migrer).

Sinon pour être plus précis, au niveau de l'interruption de service, ce qui pose problème c'est la migration des données BLOB. Pour les autres en général c'est extrêmement rapide en fonction du nombre de CPU à disposition. Les BLOBs doivent être transformé en BYTEA il faut pour cela encoder ces données et c'est ce qui prend du temps. Pour vous donner un ordre d'idée, la dernière migration que j'ai faite avait 240 GB sur une table avec des BLOB et il a fallu 16h00 avec des VM de 4 CPU et 8Go de RAM des deux cotés (serveur Oracle et serveur PG). Bien sur en dehors du hardware, tout dépend aussi de la taille des BLOBs, plus ils sont volumineux plus ils prennent des ressources à la conversion. Là c'est la première fois que je constate une telle lenteur, je pense que les VM n'y sont pas pour rien, surtout coté Oracle. A tel point que j'ai rajouté des options à la commande ora2pg permettant de visualiser à quelle vitesse Oracle est capable d'envoyer les données pour tenter de disculper Ora2Pg:

commit 955592221f6cdc649711b7bb5c982b140eaf5df1
Author: Gilles Darold <gilles@darold.net>
Date:   Fri Sep 7 17:52:03 2018 +0200

    Add two new command line options:

       --oracle_speed     : use to know at which full speed Oracle is able to send
                            data. No data will be processed and nothing written.
       --ora2pg_speed     : use to know at which full speed Ora2Pg is able to send
                            transformed data. Nothing will be written.

    they are used to be able to see at what speed Oracle is sending data and
    at what speed Ora2Pg is processing the data without reaching disk or
    direct import into PostgreSQL. Use it for debuging purpose.

Pour faire avancer les choses, si vous souhaitez mettre en œuvre le DATADIFF sur Ora2Pg je me ferai un plaisir de vous assister et de corriger/améliorer dès que possible la fonctionnalité en fonction de vos retours. Pour cela il faut reporter vos problématique sur github où à l'adresse ora2pg@darold.net. Sur github merci de le faire en anglais pour que tout le monde en profite, sur l'adresse email officiel peu importe mais c'est probablement plus compréhensible en français.

--
Gilles Darold
http://www.ora2pg.com/

Bonjour,

Effectivement ces clés étrangères faisant référence à une table dans un autre schéma n'étaient pas exportées. Ce n'est plus le cas, j'ai complètement réécrit la fonction d’extraction des foreign key et le commit d4a90fe corrige le problème. Merci de télécharger et d'utiliser le code en développement disponible sur github ( https://github.com/darold/ora2pg ).

En faisant un export d'un schéma on obtient le code suivant :

ALTER TABLE employees ADD CONSTRAINT fk_dept_deptno FOREIGN KEY (department_id) REFERENCES scott.dept(deptno) ON DELETE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE;
 

la table référencée est préfixée par le nom du schéma, ici scott. Et si l'on fait un export sans schéma, les deux tables sont préfixées par leur nom de schéma :

ALTER TABLE hr.employees ADD CONSTRAINT fk_dept_deptno FOREIGN KEY (department_id) REFERENCES scott.dept(deptno) ON DELETE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE;
 

Par la même occasion l'extraction du catalogue Oracle devrait être plus rapide aussi.

A noter que le commit précédent corrige l'absence des créations de schéma si  EXPORT_SCHEMA et CREATE_SCHEMA sont positionné à 1.

Cordialement,

Bonjour,

Le problème a été corrigé hier soir, merci d'utiliser la version en développement https://github.com/darold/ora2pg

Merci d'utiliser de préférence github pour reporter les bugs.

Cordialement,

Bonjour,

Effectivement, ce n'est pas prévu, même dans les versions récentes comme la 14.1, par contre je viens d'ajouter la fonctionnalité dans le code en développement  disponible sur github à cette adresse : https://github.com/darold/ora2pg

Par défaut, Ora2Pg provoquera automatiquement la suppression des espaces au début et à la fin des données impactées par votre conversion du type CHAR(n) vers VARCHAR(n) ou TEXT. Vous avez toutefois à votre disposition deux nouvelles directives TRIM_TYPE et  TRIM_CHAR qui permettent de contrôler ce comportement.

Notez, qu'en règle générale il n'est pas conseillé de rester sur d'anciennes versions d'Ora2Pg, elles évoluent vite, ajoutent constamment de nouvelles fonctionnalités et corrigent de nombreux bug. La liste des releases peut-être obtenue ici https://github.com/darold/ora2pg/releases ou mieux ici http://sourceforge.net/projects/ora2pg/files/ avec le changelog par version.

Cordialement,

Bonjour,

Je ne comprend pas bien. Si vous avez une table partitionnée dans Oracle vous n'avez pas a vous préoccuper des noms des partitions. Ora2Pg va vous exporter la définition de la table mère et des 14000 partitions en créant des tables filles avec leur propre nom de partition, celui que vous avez défini ('PYYYYMM'). Cela se fait effectivement avec la commande :

    ora2pg -T PARTITION

Ensuite, lorsque vous ferez l'export des données avec l'option -t COPY Ora2Pg mettra les données directement dans leur table filles respectives pour éviter de passer par la table mère et donc le trigger qui normalement redirige les données dans les tables filles.

Tout cela est automatique, du coup je ne comprend pas bien le problème que vous rencontrez. Ora2Pg supporte le partitionnement par RANGE et par LIST, mais pas le sous-partitionnement.

Cordialement,

Autre chose, je suis curieux de savoir pourquoi vous utilisez une vieille version d'ora2Pg. La 8.3 date de plus d'un an et il y a eu 12 nouvelle publication depuis. Pensez toujours à utiliser la dernière version, aujourd'hui 9.1, chaque version corrige de nombreux problèmes et ajoute son lot de fonctionnalités, c'est donc tout à fait recommandé.

Pour plus d'information : http://ora2pg.darold.net/.

Bonjour,

Il y a plus simple pour ce que vous voulez faire :

for export_type in TABLE PACKAGE COPY VIEW GRANT SEQUENCE TRIGGER FUNCTION PROCEDURE TABLESPACE ; do
    /usr/local/bin/ora2pg -t $export_type -o $export_type.sql -c /etc/ora2pg/ora2pg.conf
done

Je vous conseille la lecture de la présentation que j'ai fait au PgConf l'année dernière ou les bonnes manières d'utiliser les options et le fichier de configuration : http://ora2pg.darold.net/ora2pg-bonnes-pratiques.pdf

Concernant l'erreur, tout d'abord le <*> n'est pas un caractère inséré, c'est Oracle qui signale la position de l'erreur dans la requête. Sinon je ne comprend pas ce que vient faire MDS_PARTITIONS ici c'est probablement une table ou une vue à laquelle l'utilisateur n'a pas accès. Essayez avec un superutilisateur vu que de toute façon vous voulez exporter les droits (type GRANTS) vous aurez donc besoin des privilèges superutilisateur d'Oracle. J'entend par là un utilisateur qui a les droits DBA sous Oracle.

Dans ce cas, pouvez vous essayer de mettre en commentaire les lignes 4134 et 4168 du fichier Ora2Pg.pm et voir si cela règle le problème ? Au besoin je peux vous fournir une version modifiée du fichier.

Oui, ce que j'essayais d'expliquer c'est qu'au niveau d'Oracle les blob sont stockés par "blocs/chunk" de 4Ko par défaut ou de la taille spécifiée dans la clause storage. Lors d'une lecture (select) sur cette colonne, seul le premier bloc est retourné. Si l'on veut donc obtenir l'intégralité des données du blob lors d'un select, la taille du bloc doit donc être supérieure à la taille du plus grand enregistrement.

Voila, je ne sais pas si c'est plus clair mais le but du "alter modify blob" est d'augmenter la taille de ce bloc au maximum pour obtenir directement les données. Si cela n'est pas possible je modifierai Ora2Pg pour qu'il puisse travailler avec les blocs de BLOB.

Bonjour,

Etant donné que Ora2Pg est en pur Perl je serais tenté de dire que c'est l'installation d'Oracle, sa DLL et/ou DBD::Oracle qui n'est pas bonne ou insuffisante à moins que ce ne soit Perl lui même. S'il n'y a pas plus d'information que le "segmentation fault..." il faudrait tracer pour voir d'où vient le problème mais cela risque d'être une perte de temps à moins que vous ne teniez à aider au débogage et au support d'Ora2Pg sous Windows. En ce qui me concerne, je conseillerais vivement de l'installer sous Linux où en cas de problème de ce genre je serais plus à même de vous aider.

Cordialement,

Sinon effectivement, comme le dit kenrio, si cette erreur vous arrive alors que les tables sont déjà crées cela provient certainement d'un problème de casse. A ce moment, les directives CASE_SENSITIVE et ORA_SENSITIVE pourront vous aider.

Bonjour,

Dans les cas pratiques, je viens justement de traiter une demande de ce type ce weekend. En fait comme il n'existe pas d'outils de conversion du T-SQL vers PLPGSQL, l'utilisateur a utiliser un outil permettant de migrer du T-SQL vers du PLSQL Oracle et il voulait ensuite utiliser Ora2Pg pour convertir le code PLSQL.

J'ai donc travailler à la possibilité de fournir un fichier contenant du code PLSQL de fonctions, procédures ou packages Oracle à Ora2Pg sans avoir besoin de se connecter à une base Oracle. Évidement le fichier généré en sortie est du PLPGSQL comme Ora2Pg sait le faire, cela permettra aussi de faire avancer le code du convertisseur avec vos retours.

Cette fonctionnalité sera disponible dans la version 8.5 d'Ora2Pg qui devrait sortir d'ici la fin de semaine. Si votre outil ESF Database Migration ne permet pas de convertir le code en PLSQL, je peux essayer de me renseigner sur l'outil qu'ils ont utilisés.

Cordialement,

PS: ne pourrait-on pas renommer le forum postgresqlserver.fr pour faire plaisir à sqlpro? Cela éviterai peut-être que s'insinue dans chaque thread ce SQL Server versus PostgreSQL que je n'ose penser volontaire. A moins qu'il y ait un mode motd permettant d'introduire des liens vers les blogs et documents délivrés par celui-ci, ca ferait gagner du temps à tout le monde.