Pourquoi Char (1) passe-t-il à Char (3) lors de la copie sur un DBLINK Oracle?

Question

J'ai 2 bases de données et je souhaite transférer une table existante contenant une colonne CHAR de la base de données A vers la base de données B.

La base de données A est Oracle 9i, a le codage WE8ISO8859P1 et contient un tableau "foo". avec au moins 1 colonne de type CHAR (1 caractère). Je ne peux pas modifier la table de la base de données A car elle fait partie d’une configuration tierce.

La base de données B est ma propre base de données Oracle 10g, utilisant le codage AL32UTF8 pour toutes sortes de raisons, et je souhaite copier foo dans cette base de données.

Je configure un lien de base de données de la base de données B vers la base de données A. Ensuite, j'exécute la commande suivante:

* créer une barre de table en tant que sélection * de # link # .foo; *

Les données sont bien copiées, mais lorsque je vérifie le type des colonnes, je constate que CHAR (1 caractère) a été converti en CHAR (3 caractères) et que, lors de l'interrogation des données dans la base de données B, rembourré avec des espaces.

Je pense que quelque part sous l'eau, Oracle confond ses propres octets et caractères. CHAR (1 octet) est différent de CHAR (1 caractère), etc. J'ai entendu parler de tout cela.

Pourquoi le type de données est-il remplacé par un CHAR (3 caractères) et comment puis-je empêcher Oracle de le faire?

Edit: Cela semble être lié au transfert de CHAR entre deux niveaux de correctifs spécifiques d'Oracle 9 et 10. Il semble que ce soit vraiment un bogue. dès que je saurai, je posterai une mise à jour. En attendant, n'essayez pas de déplacer les CHAR entre les bases de données comme je l'ai décrit. VARCHAR2 fonctionne bien (testé).

Modifier 2: j'ai trouvé la réponse et l'ai publiée ici: Pourquoi Char (1) passe-t-il en Char (3) lors de la copie sur un DBLINK Oracle? Dommage que je ne puisse pas accepter ma propre réponse car mon problème est résolu.

Answer 1

Ce problème est dû à la manière dont Oracle (mis) gère les conversions de caractères entre différents jeux de caractères en fonction de la définition de la longueur de colonne d'origine. Lorsque vous définissez la taille en octets d'une colonne de type caractère, Oracle ne sait pas comment effectuer une conversion et la modifie. La solution consiste à toujours définir la longueur d'un type de caractère en caractères .

Pour une explication plus détaillée du problème et comment j'ai compris cela, jetez un oeil à http://www.rolfje.com / 2008/11/04 / transporting-oracle-chars-over-a-dblink /

Answer 2

Vous devez connaître la différence entre le WE8ISO8859P1 NLS (qui stocke les caractères dans un octet) et le AL32UTF8 qui enregistre les caractères dans un maximum de quatre octets. Vous devrez passer du temps de qualité avec Oracle National Language Support (NLS) Documentation . Oracle effectue automatiquement la conversion via le lien de base de données, dans un effort utile.

Essayez ce qui suit à partir de votre invite SQL:

ALTER SESSION NLS_NCHAR WE8ISO8859P1 
create table bar as select * from #link#.foo;

Answer 3

La première chose que je voudrais essayer est de créer la table PAS en tant que CTAS mais avec une liste de définitions de colonnes et d’essayer d’insérer les quelques milliers de premières lignes. Si cela ne réussissait pas, il serait très clair pourquoi ... et vous auriez une confirmation rapide que Thomas Low est mort de vérité.