Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'utilise ora2pg pour migrer une base Oracle vers PostgreSQL,
et le mode "COPY" pour importer les données dans la base PostgreSQL.
ora2pg permet d'extraire des données selon deux modes
- DATA : extrait les données des tables en tant que lignes INSERT
- COPY : extrait les données des tables en tant que blocs COPY
Certaines tables Oracle possédent des champs "LONG RAW" dans lesquels sont stockées des données binaires.
Ces champs ont été convertis en champ "text" en PostgreSQL par ora2pg.
L'insertion des données de ces champs ne génère aucune erreur si j'utilise le mode COPY avec ora2pg
mais je ne suis pas sûre que ces données une fois migrées contiennent toujours des données binaires.
Le mode DATA renvoie des erreurs :
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
INSERT 0 1
psql:output_data.sql:2169035: WARNING: nonstandard use of escape in a string literal
LINE 1: ...","XTV","PER_NB_N","ROW_D") VALUES (4,155,'\0\0\00...
^
Ma question concerne le fonctionnement interne de la commande COPY :
- est-ce que COPY fait un formatage / encodage à la volée des données ?
- que se passe-t-il pour les données binaires de type LONG RAW qui sont converties en text ?
- par exemple, est-ce qu'un champ "INTEGER" côté Oracle est encodé en champ "NUMBER" côté PostgreSQL ?
Merci pour votre aide.
Cordialement,
Alexandra
Hors ligne
Bonjour,
Déjà, pour commencer, LONG RAW est un type Oracle obsolète, de mémoire, pré-8i (la version qui a proposé les large objects ou lobs). Donc obsolète depuis très longtemps.
Il est donc possible, voire probable que ce type soit assez mal géré par ora2pg.
Ensuite, le type LONG RAW, comme son nom l'indique, n'est pas fait pour stocker du texte mais des données binaires. Donc côté postgresql le champ devrait être un bytea.
- est-ce que COPY fait un formatage / encodage à la volée des données ?
COPY convertit le champ texte (avec des escapes si nécessaire) en entrée vers le format du champ
- que se passe-t-il pour les données binaires de type LONG RAW qui sont converties en text ?
Ça doit poser problème, puisque Postgres va essayer de valider l'encodage de chaque caractère reçu
- par exemple, est-ce qu'un champ "INTEGER" côté Oracle est encodé en champ "NUMBER" côté PostgreSQL ?
Pas forcément. Il y a aussi un type int et un bigint côté postgresql
Dernière modification par Marc Cousin (21/01/2010 12:33:28)
Marc.
Hors ligne
Bonjour,
Merci pour votre réponse.
La base de données Oracle que je migre est une base 9i mais les types de données utilisées proviennent de Oracle 8i voire 7, donc effectivement, certains champs sont obsolètes.
Si je comprends bien ora2pg va transformé le contenu binaire des champs LONG RAW en text, est-ce correct ?
Si c'est le cas, il vaut peut-être mieux que je force ora2pg à faire la conversion des LONG RAW vers du bytea.
En ce qui concerne le formatage fait par COPY, COPY convertit les données en entrée vers le format du champ cible. Est-ce correct ?
Merci,
Alexandra
Hors ligne
Je ne connais pas parfaitement ora2pg, si nécessaire il faudra regarder davantage la façon dont il s'y prend pour faire le copy.
Il va essayer de convertir le contenu du long raw en texte, je pense (je ne sais pas trop comment il va se comporter face à ça). Le long raw n'a pas de notion d'encodage, par exemple, donc c'est à peu près garanti que quoi qu'il fasse, cela va échouer s'il essaye de l'insérer dans du text.
Il faudra, je pense, que vous convertissiez le long raw vers du bytea. A moins que votre long raw ne contienne que du texte, dont vous connaissez l'encodage. Dans ce cas, vous pouvez peut être le convertir vous même, mais cela ne sera plus automatisé. Bref, normalement bytea vous allez y arriver (j'espère), par contre si vous voulez stocker dans du texte, il faudra faire un travail pour la conversion (l'information sur l'encodage n'est pas disponible).
Marc.
Hors ligne
Merci pour votre réponse.
Je vais continuer mes essais et voir si cela aboutit.
Alexandra
Hors ligne
Pages : 1
