migration oracle9 en UTF8

Version imprimable

02/05/2007, 09h31
ljoly

migration oracle9 en UTF8
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:

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?
02/05/2007, 09h45
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]
02/05/2007, 10h09
ljoly

Citation:

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).
02/05/2007, 13h05
LeoAnderson

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 ?!
02/05/2007, 14h21
ljoly

Citation:

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.
02/05/2007, 17h40
ljoly

En effectuant la commande

Code:

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?
02/05/2007, 19h14
LeoAnderson

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

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

Code:

CREATE TABLE ...
03/05/2007, 08h52
ljoly

Citation:

Envoyé par LeoAnderson

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

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

Code:

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.
03/05/2007, 14h32
ljoly

Citation:

Envoyé par ljoly

En effectuant la commande

Code:

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?
03/05/2007, 17h18
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 :aie:
03/05/2007, 17h33
ljoly

Citation:

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 :aie:

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
03/05/2007, 17h54
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).
03/05/2007, 18h05
LeoAnderson

Citation:

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 ! :roll:
04/05/2007, 10h44
ljoly

heureusement c'était sur une base de test...
04/05/2007, 10h46
ljoly

merci pour les infos
25/05/2007, 11h24
ljoly

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.
25/05/2007, 13h05
LeoAnderson

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.
29/05/2007, 17h03
ljoly
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:

1 2 3 ITEM_DESCRIPTION -------------------------------------------------------------------------------- Schlï¿½ssel Nr. 2H 0418 fï¿½r Taschenbox
sur sqlplus sous unix avec NLS_LANG = American_America.UTF8
Code:

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?
30/05/2007, 10h18
pifor

Essayez avec NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252 et le client sqlplus graphique (sqlplusw.exe) ou Toad ou SQL Developper.
30/05/2007, 10h23
LeoAnderson

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.
31/05/2007, 19h28
louping

Citation:

Envoyé par ljoly

Bonjour,

je migre un base 8.1.7.4 en WE8ISO8859P1 vers une base 9.2.0.8 en UTF8.

Il me semble que UTF8 est inclus dans WE8ISO8859P1, et s'il y a des caractères au dela de UTF8, ca va être chaud...
Le mieux c'est de faire croire que c'est la même police afin qu'Oracle ne fasse pas de convertion.
Et là je sais plus mais mettre le NLS_LANG à UTF8 à l'export ??
Sinon, je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8...(script en C pour changer le premier mot)
A+
01/06/2007, 08h36
LeoAnderson

Citation:

Envoyé par louping

Il me semble que UTF8 est inclus dans WE8ISO8859P1

Non. :roll:

L'UTF est un unicode => il peut stocker tous les caractères, y compris le martien du sud, si nécessaire mais cela implique que la longueur d'encodage est variable

les WE8ISO... sont des jeux 8 bits iso-longueurs d'encodage => 256 caractères max. En plus, pour les WE, on n'a retenu que les caractères de l'europe de l'ouest. Les caractères des pays baltes n'y sont pas par exemple.

Citation:

Envoyé par louping

je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8

ben voyons... :roll:
en UTF, le 1er bit de l'octet indique ou non la présence d'un octet suivant... donc on ne peut pas "faire croire", sauf à prendre de gros risques...

il suffit de positionner le NLS_LANG sur l'OS...
01/06/2007, 08h40
pifor

Citation:

Il me semble que UTF8 est inclus dans WE8ISO8859P1

Non, c'est l'inverse d'après le Globalization Guide.

Citation:

Le mieux c'est de faire croire que c'est la même police afin qu'Oracle ne fasse pas de convertion.

Cela dépend: voir la FAQ OTN NLS_LANG à ce sujet par exemple.

Citation:

Sinon, je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8...(script en C pour changer le premier mot)

Le format du fichier export n'est pas documenté et modifier directement un fichier export n'est pas supporté :?
01/06/2007, 14h29
louping

Les Oracles ont parlé,

Note 260192.1 Changing WE8ISO8859P1/ WE8ISO8859P15 or WE8MSWIN1252 to UTF8 with ALTER DATABASE CHARACTERSET

You can't simply use "ALTER DATABASE CHARACTER SET" to go from WE8ISO8859P1 or WE8ISO8859P15 or WE8MSWIN1252 to (AL32)UTF8 because (AL32)UTF8 is not a binary superset of any of these character sets.
04/06/2007, 08h04
LeoAnderson

Oui, c'est exactement ce qu'on disait : you can't !

Après, ne pas confondre "superset" et "caractères gérés".

Un superset, c'est un jeu plus complet mais dont les codes des caractères communs sont identiques (par exemple WE8ISO8859P1 et WE8ISO8859P15)

la liste des caractères gérés peut être commune à 90% mais si les caractères communs n'ont pas le même codage, on dit qu'ils n'ont pas le même superset et cela complique les procédure de migration, mais cela n'influe pas (trop) sur les communications Client/Serveur

Fuseau horaire GMT +2. Il est actuellement 04h41.