migration oracle9 en UTF8

**ljoly** · 02/05/2007, 10h31

Bonjour,

je migre un base 8.1.7.4 en WE8ISO8859P1 vers une base 9.2.0.8 en UTF8. je fais un export des schémas sur la base source puis un import sur la base cible. j'ai un problème car les caractéres spéciaux (accents...) sont codés sur 2 caractères en UTF8 au lieu de 1 en WE8ISO. Cela provoque des depassements de taille de colonnes et le message suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
IMP-00019: row rejected due to ORACLE error 1401
IMP-00003: ORACLE error 1401 encountered
ORA-01401: inserted value too large for column

Je n'ai pas la possibilité de modifier le format des tables.
Quelqu'un a t'il déjà rencontré ce type de problème?

**LeoAnderson** · 02/05/2007, 10h45

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

**ljoly** · 02/05/2007, 11h09

Envoyé par LeoAnderson

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je n'ai pas la possibilité de créer les tables car il s'agit d'un migration oracle application 11.0.3 vers oracle e-business 11.5.10. Le shema de données sur la base cible est créé par l'installation standard (rapidwiz).

**LeoAnderson** · 02/05/2007, 14h05

si vous faites un import qui créé les tables, je ne vois pas en quoi vous ne pouvez pas créer les tables à la main ?!

**ljoly** · 02/05/2007, 15h21

Envoyé par LeoAnderson

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je viens d'essayer, ça ne fonctionne pas, j'ai le même message d'erreur.

**ljoly** · 02/05/2007, 18h40

En effectuant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?

**LeoAnderson** · 02/05/2007, 20h14

Allez-y ! essayez tout et ensuite, à nous de réfléchir ?

je vous avais conseillé de créer les tables, pas de les importer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE ...

**ljoly** · 03/05/2007, 09h52

Envoyé par LeoAnderson

Allez-y ! essayez tout et ensuite, à nous de réfléchir ?

je vous avais conseillé de créer les tables, pas de les importer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE ...

il s'agit d'une base e-business 8, càd plusieurs centaines de tables, ça serait trop long à recréer les tables une par une.

**ljoly** · 03/05/2007, 15h32

Envoyé par ljoly

En effectuant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?

Qui peut me dire ce que fait exactement le alter database?
Dans metalink on me conseille d'effectuer également un csscan avant, A quoi ça sert? ça génére juste un report avec les lignes non convertibles ou tronqués?

**pifor** · 03/05/2007, 18h18

Les commandes ALTER DATABASE SET CHARACTER USE ou ALTER DATABASE SET CHARACTER INTERNAL_USE ne font pas de conversion des colonnes contenant des caractères mais change le jeu de caractères déclaré de la base d'après la note Metalink 66320.1.

CSSCAN permet de vérifier que les données existantes seront bien reconnues dans le nouveau jeu de caractères: il ne doit signaler que des données ChangeLess sinon il y aura incohérence entre le jeu de caractères déclaré de la base et les données de la base

**ljoly** · 03/05/2007, 18h33

Envoyé par pifor

Les commandes ALTER DATABASE SET CHARACTER USE ou ALTER DATABASE SET CHARACTER INTERNAL_USE ne font pas de conversion des colonnes contenant des caractères mais change le jeu de caractères déclaré de la base d'après la note Metalink 66320.1.

CSSCAN permet de vérifier que les données existantes seront bien reconnues dans le nouveau jeu de caractères: il ne doit signaler que des données ChangeLess sinon il y aura incohérence entre le jeu de caractères déclaré de la base et les données de la base

Je n'ai que des 'convertible', 'lossy conversion', 'exceed column size'. Connaissez-vous la signification ces valeurs? et les conséquences sur la base de donnée convertie

**pifor** · 03/05/2007, 18h54

convertible: peut être converti uniquement par export/import.
lossy: ne peut être converti par aucun moyen.
exceed column size: les données seront tronquées s'il y a conversion, car la colonne est trop petite (les nouveaux caractères prennent au moins 2 octets au lieu d'un seul).

**LeoAnderson** · 03/05/2007, 19h05

Envoyé par pifor

convertible: peut être converti uniquement par export/import.
lossy: ne peut être converti par aucun moyen.
exceed column size: les données seront tronquées s'il y a conversion, car la colonne est trop petite (les nouveaux caractères prennent au moins 2 octets au lieu d'un seul).

en d'autres termes et vu que vous avez déjà effectué l'alter database, vous avez pourri vos données !

**ljoly** · 04/05/2007, 11h44

heureusement c'était sur une base de test...

**ljoly** · 04/05/2007, 11h46

merci pour les infos

**ljoly** · 25/05/2007, 12h24

Je ne comprends pas, j'ai effectué un scscan, qui m'a renvoyé juste un pb de 'exceed column size', après conversion par 'alter database character set internal_use UTF8' , j'ai des caractères spéciaux qui sont remplacés par des ?. Y a t'il un paramétrage à effectuer (dans la base ou sur le client) afin qu'ils s'affichent correctement.

**LeoAnderson** · 25/05/2007, 14h05

oui, vous devez positionner le NLS_LANG sur le client afin de dire quel jeu de caractères vous souhaitez utiliser.

Si vous choisissez un jeu qui ne contient pas certains des caractères stockés, vous aurez des ? ou des points d'interrogations inversés à la place.

**ljoly** · 29/05/2007, 18h03

J'ai quelque chose de bizarre, pour une même requête

sur sqlplus sous windows avec NLS_LANG = AMERICAN_AMERICA.UTF8, j'ai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ITEM_DESCRIPTION
--------------------------------------------------------------------------------
Schlï¿½ssel Nr. 2H 0418 fï¿½r Taschenbox

sur sqlplus sous unix avec NLS_LANG = American_America.UTF8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ITEM_DESCRIPTION
--------------------------------------------------------------------------------
Schlüssel Nr. 2H 0418 für Taschenbox

Y a t'il quelque chose d'autre à configurer au niveau du client oracle ou au niveau du listener?

**pifor** · 30/05/2007, 11h18

Essayez avec NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252 et le client sqlplus graphique (sqlplusw.exe) ou Toad ou SQL Developper.

**LeoAnderson** · 30/05/2007, 11h23

le problème est que Oracle ne peut pas faire mieux que le système.

Il est probable que sous windows l'UTF soit mal géré, notamment sur un vieux Windows et/ou que le SQL*Plus graphique (qui est à éviter à tout prix !) en soit lui-même incapable !

Ce n'est pas Oracle qui ne fonctionne pas, c'est le programme client et/ou l'OS.
Essayez sous SQL*Plus en mode texte.

migration oracle9 en UTF8

Administration Oracle

Discussions similaires

Partager

Partager